Use configure.ldflags-delete instead of configure.ldflags?
Gellule Xg
gellule.xg at free.fr
Tue Mar 15 13:22:46 PDT 2011
>> How about the addition of "-Xlinker -headerpad_max_install_names"
>> as a
>> default in portconfigure.tcl? Would macport consider it?
>
> We could consider that. I wonder if there are any negative
> implications for any ports? Have you already been trying this on many
> ports, with positive results?
I would not be able to answer your first question.
I managed to build the dependencies for inkscape (the reason why I am
doing all this) with "-Wl,-headerpad_max_install_names" added to
portconfigure.tcl without apparent problem. I only have libiconv and
ncurses Porfiles modified with configure.ldflags-delete and
configure.cppflags-delete, but there are other ports that would need
such a modification. The issues I had with using install_name_tool are
gone. For me it looks like -headerpad_max_install_names had been applied
to a sufficient number of dependencies of inkscape to keep me going.
I haven't checked either that the universal build issue for libiconv and
ncurses, that was addressed by adding configure.ldflags to empty, is
also addressed with configure.ldflags-delete.
> Explicitly deleting just -L${prefix}/lib is fragile, however, and 'ldflags' should (imho) be safe for a port to simply reset. This seems demonstrative of the problems that can emerge with base implicitly setting environmental variables and other build-time arguments; it's much harder to control them directly from a port when you need something different.
>
> -landonf
>
In a Macports IRC log the idea of intercepting ld was proposed:
http://echelog.matzon.dk/logs/browse/macports/1258844400 at [22:20:58]
It does not require any change to the Portfiles. Would it be a better
way? Does it look like something that could be integrated into Macports?
More information about the macports-dev
mailing list