Use configure.ldflags-delete instead of configure.ldflags?
Ryan Schmidt
ryandesign at macports.org
Mon Mar 14 18:13:21 PDT 2011
On Mar 14, 2011, at 19:29, Gellule Xg wrote:
> I am trying to have "-Xlinker -headerpad_max_install_names" added to all
> ports' ldflags by modifying
> /opt/local/share/macports/Tcl/port1.0/portconfigure.tcl, replacing
> default configure.ldflags by:
> default configure.ldflags {"-L${prefix}/lib -Xlinker
> -headerpad_max_install_names"}
> This would help with the use of install_name_tool to relocate
> libraries produced by macports. I understand that macports results are
> not meant to be relocated.
>
> However, a few ports erase configure.ldflags in the Portfile definition
> by using configure.ldflags set to empty. This is case for e.g. libiconv.
> For this Port, the reason for this is described in
> https://trac.macports.org/changeset/33625: "libiconv: make it possible
> to build a universal libiconv even when a non-universal libiconv is
> already active." Looking through the comments, it seems that:
> configure.ldflags-delete -L${prefix}/lib would be sufficient. (And for
> symmetry, configure.cppflags-delete -I${prefix}/include)
>
> There are other reasons for removing -I${prefix}/include and
> -L${prefix}/lib, that use a set configure.ldflags or configure.cppflags
> to empty. They could maybe be replaced by a configure.ldflags-delete or
> configure.cppflags-delete as well.
>
> Is that something (the replacement of configure.ldflags by
> configure.ldflags-delete, and its cpp flags equivalent) macport would
> consider?
Sounds like a good suggestion. Right now, the two are equivalent, but it might be better for ports to specify exactly what they mean -- i.e. if deleting -L${prefix}/lib is what's desired, the port should say that, rather than assume that's all that's in the ldflags and just clear them completely.
> 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?
More information about the macports-dev
mailing list