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