[104258] trunk/base/src/port1.0/portconfigure.tcl

[Rainer Müller]

On 2013-05-05 14:11, Andrea D'Amore wrote:
> On Sun, May 5, 2013 at 11:53 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
>>> (I've been passing options to ld 134.9 on purpose to test this),
>>> should we make that line
>>>    default configure.ldflags   {"-L${prefix}/lib -headerpad_max_install_names"}
>>> instead?
>>
>> I haven't noticed any ill effects from using -Wl,-headerpad_max_install_names; have you?
> 
> No, I haven't. I was trying to track down an issue with macports'
> luajit and noticed this while reading the log.
> 
> Again, even if the man page doesn't mention it, and ld64 sources from
> Apple doesn't contain the code to parse "-Wl" it seems to work, you
> can countercheck by setting a -arch option in CFLAGS and then a
> different one in LDFLAGS using "-Wl,-arch,", the linker will complain.

Both CFLAGS and LDFLAGS are passed by the compiler, as Makefiles usually
use $(CC) for both compiling and linking.

>> Tons of projects misuse the *FLAGS variables and put them in the wrong places, so I'm sure there are projects that use LDFLAGS even when not linking. My understanding is that "-Wl," ensures that the flag will only get passed to the linker.
> 
> I know, lot of makefiles pass LDFLAGS to compile commands rather than
> to link ones so that justifies the use of "-Wl," since it's a compiler
> option.
> Should we just follow the trend and use an undocumented option for the
> sake of ease or should we switch ti -headerpad_max_install and
> patch/report upstream those softwares who do not comply?

-Wl is a documented option for the compiler (both clang and gcc) and it
is used to pass options to the linker.

> I'd prefer the latter unless somehow it turns out -Wl, is an official
> ld option that is just not documented.

When calling the compiler executable for linking, using -Wl would
actually be more accurate.

Rainer