Mercury Bugs - mercury
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000104mercuryBugpublic2009-09-14 13:552009-10-06 08:40
Reportercolanderman 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusfeedbackResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000104: Static linking doesn't properly track dependencies
DescriptionLet 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 InformationNormally 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.
TagsNo tags attached.
Relationships
Attached Files

Notes
(0000195)
juliensf   
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.
(0000197)
colanderman   
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.

Issue History
Date ModifiedUsernameFieldChange
2009-09-14 13:55colandermanNew Issue
2009-10-06 02:36juliensfNote Added: 0000195
2009-10-06 02:36juliensfStatusnew => feedback
2009-10-06 08:40colandermanNote Added: 0000197