| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0000433 | mercury | Bug | public | 2017-03-23 15:04 | 2018-03-13 14:38 | ||||||||
| Reporter | pbone | ||||||||||||
| Assigned To | pbone | ||||||||||||
| Priority | normal | Severity | minor | Reproducibility | have not tried | ||||||||
| Status | acknowledged | Resolution | open | ||||||||||
| Platform | amd64 | OS | Linux Mint | OS Version | |||||||||
| Product Version | |||||||||||||
| Target Version | Fixed in Version | ||||||||||||
| Summary | 0000433: mmc --make calls programs without full path | ||||||||||||
| Description | if you have multiple installations of Mercury then calling tools like mkinit without the full path can lead to problems. | ||||||||||||
| Steps To Reproduce | I have two installations of Mercury. In /usr I have 14.01.1 (this is the one I'm filing the bug against). And I have a recent ROTD in /usr/local (linked there by stow, stow is cool, check it out). But /usr/local is earlier in my path than /usr so that I can override my system's tools. $ which mmc /usr/local/bin/mmc If I invoke the version in /usr it breaks. $ /usr/bin/mmc --make hello Making Mercury/int3s/hello.int3 Making Mercury/ints/hello.int Making Mercury/cs/hello.c Making Mercury/os/hello.o ** Error making `hello'. Mercury/cs/hello_init.c: In function ‘mercury_init’: Mercury/cs/hello_init.c:1736:29: error: ‘ML_std_library_init’ undeclared (first use in this function) Mercury/cs/hello_init.c:1736:29: note: each undeclared identifier is reported only once for each function it appears in Mercury/cs/hello_init.c:1737:27: error: ‘ML_std_library_finalize’ undeclared (first use in this function) Mercury/cs/hello_init.c: At top level: Mercury/cs/hello_init.c:1866:1: error: expected identifier or ‘(’ before ‘/’ token It appears to be excuting the first mkinit it finds in my $PATH, which is incompatible. If I override $PATH, then it works without a problem. | ||||||||||||
| Additional Information | I intend to fix this bug in the immediate future, I'm filing it now so that I can have a URL to point to it. | ||||||||||||
| Tags | No tags attached. | ||||||||||||
| Attached Files |
| ||||||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
pbone (administrator) 2017-04-05 11:02 |
I've been looking at this issue. I'd like to store the full path to each of these tools (mkinit, mgnuc etc) in the configuration. scripts/Mercury.config.in seems like the best place to do that, and a similar change will need to be made for Mmake. It's also desirable to use the libexec directory, and in particular allow ./configure to set these directories rather than creating them ourselves, ignoring ./configure. However that may make it a little tricker to "move" a mercury installation, but that too should be solvable. Does anyone else seen any potential problems we may create by encoding the full paths in Mercury.config and allowing these files to be installed in different locations via ./configure's parameters? Thanks. |
|
wangp (developer) 2017-04-05 11:24 |
I think using full paths is the correct thing to do. Allowing configure to adjust locations may get in the way of a different goal. I would like to see mmc --make and mmake use absolute paths built at runtime relative to a top-level directory either (1) deduced automatically based on the full path to mmc or mmake, or (2) manually overridden. This would allow moving the Mercury installation without touching any files. It would be especially useful for making prebuilt binary packages that could run immediately out of any user's home directory. (C compiler differences may still hamper that.) |
|
pbone (administrator) 2017-04-05 11:40 |
We can already move an installation by editing/rebuilding Mercury.config (and maybe another file). This change would make it more difficult to move an installation, there's just be more to edit within Mercury.config since it wouldn't build paths at runtime. There's another option. Rather than either writing (in Mercury.config) the path to each tool/library, or writing the prefix and building paths at runtime, we could write the path to @bindir@ and @libexecdir@ and build paths from those at runtime. It'd be a little easier to move an installation, but give full flexibility to autoconf/building packages for distros. I think either this, or writing the path to each tool in Mercury.config is the correct thing to do. There may be other ways to move an installation, such as by providing a simpler Mercury.config file that is based on most Linux distros' defaults with only one variable for the prefix. |
|
wangp (developer) 2017-04-05 12:01 |
You can edit Mercury.config, but it is too difficult. Using Mercury on any (recent) Linux distribution should be as easy as tar xf mercury-bindist-xxxx.tar.gz I'm wary of introducing a variable syntax to Mercury.config. Which locations need customisation? I don't think anyone would object to libexec. If I remember, we had agreement to move most scripts out of bin. |
|
juliensf (administrator) 2017-04-05 12:03 |
Files containing paths are: lib/mercury/conf/Mercury.config lib/mercury/mdb/mdbrc lib/mercury/mmake/Mmake.vars as well as a bunch of scripts in the bin directory. Also, macOS you won't just be able to shift an installation without rewriting all of the install_names in the dylibs. @wangp: C compiler differences will definitely hamper that! In principle, we could build information about known C compilers into the system, so that by setting --cc, --c-compile-type and --fullarch appropriately it would select the correct set of flags. (I think I posted something to the developers list about this several years ago.) Of course, you will still have a problem with new C compiler versions that the Mercury compiler doesn't know about. |
|
pbone (administrator) 2018-03-13 14:38 |
Unassigned things from me. |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-03-23 15:04 | pbone | New Issue | |
| 2017-03-23 15:04 | pbone | Status | new => assigned |
| 2017-03-23 15:04 | pbone | Assigned To | => pbone |
| 2017-04-05 11:02 | pbone | Note Added: 0000946 | |
| 2017-04-05 11:24 | wangp | Note Added: 0000947 | |
| 2017-04-05 11:40 | pbone | Note Added: 0000948 | |
| 2017-04-05 12:01 | wangp | Note Added: 0000949 | |
| 2017-04-05 12:03 | juliensf | Note Added: 0000950 | |
| 2018-03-13 14:38 | pbone | Status | assigned => acknowledged |
| 2018-03-13 14:38 | pbone | Note Added: 0000977 | |
| Issue History |