Use configure.ldflags-delete instead of configure.ldflags?

[Anders F Björklund]

Ryan Schmidt wrote:

> We may not particularly support what this user is doing, but we may very well want to support doing this when we start building and distributing binary packages, so that they could be relocated to whatever prefix the user installed MacPorts to.

If you are planning to use the current "archives" to do so, you could have a problem with the prefix being included in the file paths. Easy enough to "cd" when extracting, maybe it's mostly pathname bloat (an extra /opt/local per file).

I think that relocatable packages are great BTW, just a much bigger order than adding LDFLAGS ? Supporting that properly would be a worthy challenge, and open up for building packages as non-root (to not prefix /Users/name/.macports).


> Therefore we may want to add the flags for max header padding to the default configure.ldflags in MacPorts as suggested. This would necessitate revisiting portfiles that currently clear configure.ldflags under the assumption that only -L flags are in there.

That's still a bug, though.

> So, I return to your initial response:
> 
>>>>>> 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.
>>> 
> 
> and ask you to clarify your objection to this proposal.

Don't think that was mine.

I'm all for hacking out random environment variables in ports. :-)
But the problem itself is the same as with CFLAGS versus optflags ?
Sometimes you just want to avoid -O3 etc, but remove "needed" flags.

But you *could* do an LD wrapper, just like one can wrap CC for arch.
(i.e. do an "ld" stub that would add a -headerpad_max_install_names,
just like one can have "gcc" wrappers that are prefixed with triplets)

--anders