www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 9805] New: DFLAGS append behavior insufficient, DFLAGS_PRE also needed

reply d-bugmail puremagic.com writes:
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
next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling parent d-bugmail puremagic.com writes:
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