Bug 2776 – pragma(lib, does not work when used in headers

I tried to use the pragma(lib, ...) feature without success. I build a lib called "org.eclipse.swt.win32.win32.x86.lib", the source contain several pragma declarations: pragma(lib, "comctl32.lib"); // and more win32 libs pragma(lib, "org.eclipse.swt.win32.win32.x86.lib"); // link to the lib itself The module with those pragmas is always imported if the lib is used. Now, when i compile a example using the lib and turn on verbose, dmd prints all those lib lines ... library comctl32.lib library org.eclipse.swt.win32.win32.x86.lib ... Later it prints the commands it passes to "link.exe", here the libs are missing: c:\Project\dwtinst\tango-0.99.8-bin-win32-dmd.1.041\bin\link.exe "C:\Project\dwtinst\dwt-rcp\obj\SwtSnippet10","C:\Project\dwtinst\dwt-rcp\bin\SwtSnippet10.exe",,user32+kernel32/noi+C:\Project\dwtinst\dwt-rcp\lib\+tango-user-dmd.lib; The result are all those symbols are missing.

In DMD sources, the addition to the linker of the pragma(lib,..) happens in attrib.c: PragmaDeclaration::toObjFile which like the name implies while object file generation. This is not happening for headers. So I think the solution should be to move this to the semantic() method.

Just found this myself. This feature is much more useful when used for dependencies for libraries, than for building applications directly. As long as the external library files are available, the application developer would only have to worry about linking the library he is using, not also those used by that library.

Created attachment 377 This patch should fix the problem The patch is for dmd v1.045 and tested with Mac OS X.

This issue still exists. Is anyone able to update this patch for latest versions of DMD (2.x included) and make a pull request on github?

There are a couple problems with this patch. 1. It moves up to the semantic phase a call to set the include lib in an obj file. This is completely outside how obj files are written, and mucks up the separation of passes. It shouldn't work at all. 2. Lots of projects have a tendency to import lots of things. Sometimes none of it is referenced, sometimes only a minor declaration is referenced, sometimes the import is an unneeded private import of some other module. Demanding then that the referenced library exist and be linked in can cause its own frustrations and problems. I don't know if there is a good solution to these problems. I don't think the patch is it.

DSSS/rebuild/bu(il)d adds its on pragma, pragma(link, ...), which basically works like pragma(lib, ...) with this patch. Except when linking a library with pragma(link) you only specify the name of the library and then it automatically adds the extension depending on the platform. It also prefix the library name with "lib" on Posix systems. Could we add a pragma(link) that behaves as the one in DSSS/rebuild/bu(il)d, this won't break any existing code, if I'm not missing something? I would also like something for frameworks on Mac OS X, see: http://d.puremagic.com/issues/show_bug.cgi?id=2968

Has this been verified to be only for D1?

(In reply to comment #7) > Has this been verified to be only for D1? Not yet. But Walter is only converting the tags from D1.x to D1, and D2.x to D2.

(In reply to comment #8) > Not yet. But Walter is only converting the tags from D1.x to D1, and D2.x to > D2. I see. But why not set it to "D1 & D2" when it's uncertain? Unless it's obvious it can only be for one version.

(In reply to comment #9) > (In reply to comment #8) > > > Not yet. But Walter is only converting the tags from D1.x to D1, and D2.x to > > D2. > > I see. But why not set it to "D1 & D2" when it's uncertain? Unless it's obvious > it can only be for one version. Because there are some bugs that are marked "D1 & D2" which /are/ actually both D1 and D2 bugs. We shouldn't introduce false-positives. Anyway depending on arbitrary meaning for these tags is probably a bad idea, why not introduce a new keyword "verify_D2" or something like that for bugs that should be checked whether they might also apply to D2?

(In reply to comment #10) > Because there are some bugs that are marked "D1 & D2" which /are/ actually both > D1 and D2 bugs. We shouldn't introduce false-positives. Then setting it to D1 would not be correct either. > Anyway depending on arbitrary meaning for these tags is probably a bad idea, > why not introduce a new keyword "verify_D2" or something like that for bugs > that should be checked whether they might also apply to D2? Sure, there's already a version "unspecified". I'm pretty certain this particular bug applies both for D1 and D2, that's why I reacted.

(In reply to comment #11) > (In reply to comment #10) > > > Because there are some bugs that are marked "D1 & D2" which /are/ actually both > > D1 and D2 bugs. We shouldn't introduce false-positives. > > Then setting it to D1 would not be correct either. But it already was, he just changed D.X into D1. Or is that still an issue? > Sure, there's already a version "unspecified". I'm pretty certain this > particular bug applies both for D1 and D2, that's why I reacted. Well either way we have a lot of work to do testing and verifying these bugs. :)

(In reply to comment #12) > But it already was, he just changed D.X into D1. Just because it's set to DMD 1.x doesn't mean it's only for D1. The creator of the bug report could have set it to latest versions available when it was created. > Or is that still an issue? I'm pretty certain it is. I have not heard of any changes related to pragma(lib). > Well either way we have a lot of work to do testing and verifying these bugs. > :) Absolutely.

*** Issue 11523 has been marked as a duplicate of this issue. ***

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/17926 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB