[JJR]

I've finally tracked down a "minor" issue with build. Well, it not so much a problem with build, I guess; but build propogates the error so to speak when I use linux.

It goes like this:

- Compile a D library with build...
- Compile your project with build and include your D library on the command line with the -L-l command (assuming your D libraries are on the system library path).

If you do the above, the project link phase will die on missing symbol errors mostly relating to missing phobos symbols. libphobos.a is automatically included in all d programs, so these errors at first don't make sense. But to appease the linker we add a -L-lphobos back on to the command line (second time). This clears up all previous errors. Program links. But executable crashes on run.

Solution:

Instead of using the linker passthrough switch for libraries (-L-l), avoid it like the plague when you are linking your own D libraries in with your program (the method otherwise works fine with C system libraries, though)! Use a direct link to your d library with the full path instead:

dmd project.d /my/library/path/libmylib.a [other options]

At least I tried the above with dmd directly (using -L-l with dmd causes the same problem as that with build). I assume it should work the same with build. At least build should submit the above in the same form to dmd or else trouble continues. If the library is submitted this way, the resulting executable runs correctly with no errors. Furthermore there is no need to try to fix the problem with a tacked on -L-lphobos for symbol resolution.

What happens is that dmd seems to get the required symbols immediately submitted to the linker when using the above format, whereas the -L-l switch tacks them on late, which somehow causes the linker to not see phobos symbols for your -L-l included D library. Trying to fix the missing symbols with a redundant -L-lphobos causes major conflicts that crash the program.

I'm not sure if the pragma(link...) command causes the same problem, but I'm pretty sure it does as long as it passes on the command in a -L-l form to the linker. Once again this is true of D libraries. C libraries don't seem to have this issue.

So perhaps this is more of a warning than a request for a fix. Although it would be appropriate if the pragma(link...) could be fixed to submit the library to the command line in the appropriate format, otherwise D libraries won't link in as expected and the resulting program won't run. I'm not sure what action is necessary, since in actually fact using an -L-l should work in the first place!

-JJR

[Derek Parnell]

[JJR]

Perfect!

Then count me in for the testing phase.

-JJR

[teqdruid]

[JJR]

John,

I agree that using -L-l is generally the proper approach for submitting a library to the linker. That's why, if it worked correctly all the time, it would be the preferred way to link in a D library. When passing a D library directly to DMD, however, I've found that it only works if you include the library directly on the command line (in this case DMD manages submitting the library to the linker). This way is no less incorrect where D specific libraries are concerned. It's just an inappropriate option where the pragma(link, ...) directive is used.

For some strange reason, as I describe previously -L-l does not work properly in some cases. In the next few days, I'll try to submit an example for you to try that reproduces the problem (been busy lately).

Also, I qualified that -L-l should work in the first place. Thus, I agree that pragma(link, ...) should be using this method. But since it appeared to be failing, I was open to an alternate solution to solve my problem.

I think it odd that, in my case, dmd seems to submit libraries to the linker in very different orders depending on whether an -L-l switch is used or the library is supplied directly on the command line.

I'll try to submit an example that reveals the problem I'm experiencing.

-JJR

[teqdruid]

We've had this argument before with build. It's possible that dmd is changing the order of the -l's and that's doing something, but since Derek is re-writing it to use gcc directly, that shouldn't be an issue anymore.

If there's an issue with the -l switch, we need to get that issue fixed rather that attempt a rather difficult workaround. The only other way for build to do it is to search through the library path in the same manner as gcc, which seems unnecessary to me.

Considering how hard it was to get it right last time, I'd just rather not go through it again. Sorry if my response seemed a little hard-lined.

~John Demme

[JJR]

My gaff must have been that I didn't realize the discussion occurred before (or maybe I just forgot ). I'm afraid I wasn't arguing for any particular method of fixing the problem. I was just providing the only solution I knew myself.

Since Derek seems to be working on a overall solution, perhaps there's nothing more for me to really say on the matter now. I'm very greatful for any solution, though.

Given that you've wrangled about these linking issues before, I can certainly understand your minor impatience.

-JJR

[JJR]

As fate would have it, the problem is no longer reproducible in its entirety. I'm not sure why since the original problem used to happen all the time for me.

Yet, adding another -L-lphobos is still necessary to avoid missing symbol errors in the linker. This should not be the case as phobos is already submitted to the linker at an earlier stage (as revealed by the build output).

Nonetheless the resulting executable now runs without error contrary to what I indicated before. That's good news. So if Derek can streamline how build organizes the linking process so that -L-l works without adding another -L-lphobos then all should be just about perfect.

-JJR

[Carlos]

I'm not sure of what you're doing, John, and I don't remember the details exactly, but I think something like this happens: when you do "dmd foo.d -L-lmylib", DMD passes to gcc "gcc -o foo foo.o -lphobos -lm -lpthread -lmylib", or something like that, so if mylib depends on phobos, ld fails. The workaround is to just compile with DMD and then do "gcc -o foo foo.o -lmylib -lphobos -lm -lpthread".

[Derek Parnell]

[JJR]

Carlos,

You're correct. I'm afraid I came to the same conclusion after some trial and error. I wish I had played with this a little more before posting so much redundant mumbo jumbo.

It makes sense now. Although it didn't seem to work correctly before (as in several months ago). Thanks, guys, for putting up with me on this one.

-JJR