2024-10-15 22:35 AEDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000104mercuryBugpublic2009-10-06 08:40
Reportercolanderman 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusfeedbackResolutionopen 
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.
Attached Files

-Relationships
+Relationships

-Notes

~0000195

juliensf (administrator)

--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 (reporter)

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