digitalmars.D.bugs - [Issue 9805] New: DFLAGS append behavior insufficient, DFLAGS_PRE also needed
- d-bugmail puremagic.com (44/44) Mar 24 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9805
- d-bugmail puremagic.com (16/16) Mar 24 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9805
- d-bugmail puremagic.com (16/16) Mar 24 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9805
- d-bugmail puremagic.com (7/7) Mar 24 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9805
- d-bugmail puremagic.com (7/7) Mar 24 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9805
http://d.puremagic.com/issues/show_bug.cgi?id=9805 Summary: DFLAGS append behavior insufficient, DFLAGS_PRE also needed Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: j.e.aten gmail.com --- Related to Issue 6822, recent alterations in the Ubuntu (showed up in 12.04 precise for me) default options to the linker ld make it so that the argument order to the linker can become critical. Details: https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition Case study: In order to successfully link the Thrift bindings for D during a make check on the D test suite for Thrift (https://github.com/apache/thrift.git), I was forced to manually pre-pend options to the dmd command line. Fortunately there were only 6 files that needed manually compiling, but had the project been larger, the lack of a way to prepend compiler and linker options to the dmd command line would have been disastrous. As the documentation for DFLAGS notes, these options are suffixed (appended) to the dmd command line. Unfortunately the recent linker default changes in Ubuntu (--as-needed is now the default in 12.04, ugh) makes the linker very sensitive to the exact sequence and order of the linker options. Example of non-successful compile: (note that the -L--no-as-needed is at the end, the same place that DFLAGS in dmd.conf places it) dmd -L-levent ../libthriftd-event.a -L-lssl -L-lcrypto ../libthriftd-ssl.a -w -wi -O -release -inline -I../../../lib/d/src -Igen-d ../../../lib/d/libthriftd.a -ofclient_pool_test client_pool_test.d -L--no-as-needed Example of successful compile: dmd -L--no-as-needed -L-levent ../libthriftd-event.a -L-lssl -L-lcrypto ../libthriftd-ssl.a -w -wi -O -release -inline -I../../../lib/d/src -Igen-d ../../../lib/d/libthriftd.a -ofclient_pool_test client_pool_test.d The only difference is that the -L--no-as-needed comes at the beginning. Hence we should implement an additional version of DFLAGS called DFLAGS_PRE that prepends instead of appends its options to the dmd command line. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 24 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9805 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla digitalmars.com 12:53:26 PDT --- I don't think there's a solution to this problem - various versions have come up for it before, and the solutions work for one incarnation and not for another, besides being awfully confusing. A better way when one needs a custom link line is to eshew doing it with dmd, and use gcc instead. (After all, all dmd does to do the link is fork gcc.) If you compile with -v, you can see the command passed to gcc. Capture that command, then modify it as required and put it in your makefile. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 24 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9805 --- I agree that there's not a perfect solution to this problem. Whenever one has to deal with a third-party makefile like in this case, from thrift, it's always a bit of a hack that is needed when it breaks on you. As you point out, there are more precise ways to deal with the more general problem, but these don't necessarily apply to the third-party situation where I don't control the makefile and it's very complicated itself. I thinks it is a Pareto 80/20 trade off. For my case and some of the previously reported cases, LDFLAGS_PRE would suffice, and provide a quick and high value solution. Also, being able to insert _PRE in dmd.conf and note the effect would be of strong value during the diagnostics, troubleshooting, and debugging phases of fixing link issues. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 24 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9805 --- Submitted pull request 1794 https://github.com/D-Programming-Language/dmd/pull/1794 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 24 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9805 --- Previous pull request was against the wrong branch. Against the correct master: https://github.com/D-Programming-Language/dmd/pull/1796 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 24 2013