| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0000104 | mercury | Bug | public | 2009-09-14 13:55 | 2009-10-06 08:40 | ||||||||
| Reporter | colanderman | ||||||||||||
| Assigned To | |||||||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||||||
| Status | feedback | Resolution | open | ||||||||||
| Product Version | |||||||||||||
| Target Version | Fixed in Version | ||||||||||||
| Summary | 0000104: Static linking doesn't properly track dependencies | ||||||||||||
| Description | Let there be two libraries, a and b, and one program, c. Let b use a (in Mercury.options: EXTRA_LIBRARIES = a) and c use b (EXTRA_LIBRARIES = b). Compile a with "mmc --generate-mmc-deps -m liba.install", b with "mmc --generate-mmc-deps -m libb.install", and c with "mmc --linkage static -m c". Linking c will fail, since only libb.a is linked, and it doesn't contain symbols from liba.a which are necessary to produce the final executable. | ||||||||||||
| Additional Information | Normally this isn't a problem with shared linking, because shared objects (at least on Linux) track this sort of dependency information for you. Nonetheless I have ran into this problem once with shared linking under 0.13.1: the asm_fast.gc.mmsc.debug grade of a library failed to build because its .c file directly referenced a constructor which the .m file could not see (it was nested two levels deep). (Linking would have succeeded, but compilation failed.) The problem was "resolved" by changing the definition of the type which was "leaking" from an alias to a constructor -- clearly not something that should have any effect. I have been unable to reproduce this error with a small test case but if I am able to I will supply it. | ||||||||||||
| Tags | No tags attached. | ||||||||||||
| Attached Files |
| ||||||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
juliensf (administrator) 2009-10-06 02:36 |
--generate-mmc-deps does *not* track library dependencies only module ones. You need to specify the that c also uses a, either via the --ml option or explicitly listing it in the Mercury.options file. |
|
colanderman (reporter) 2009-10-06 08:40 |
That's exactly the problem -- it *should* track C library dependencies. I, as the writer of c and the user of b, should not need to know that b uses a. This is a leaky abstraction which induces build brittleness: if the author of b decides in version 1.2.7 that library d does the job better than a, then I require two different build scripts for *my* user depending on whether he has version 1.2.6 or 1.2.7 of library b. Objective Caml provides a good example of how to properly handle this situation. It tracks C library dependencies (even external ones) as well as ML library dependencies. |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-09-14 13:55 | colanderman | New Issue | |
| 2009-10-06 02:36 | juliensf | Note Added: 0000195 | |
| 2009-10-06 02:36 | juliensf | Status | new => feedback |
| 2009-10-06 08:40 | colanderman | Note Added: 0000197 | |
| Issue History |