Prev: tabstop setting for port Makefiles
Next: nagios-plugins-1.4.14_1,1 Configure Error, libtool15 to blame
From: Anonymous on 11 Jul 2010 11:26
"b. f." <bf1783(a)googlemail.com> writes:

[...]
> http://www.freebsd.org/doc/en_US.ISO8859-1/articles/custom-gcc/configuring-ports-gcc.html
>
> Despite claims of 100% backwards-compatibility for these libraries,
> this remapping will have some consequences,

Did you miss ports/148196? ld(1) ignores libmap.conf and will try to
link from libs in /usr/lib before $LOCALBASE/lib if it can unless you
alter linker hints. For any lib specified with `-l' I don't think even
hints are used.

> so you may want to check if you have disabled the remapping while
> building/installing the base system, which I would recommend. And to
> be on the safe side, I would do this by editing or temporarily moving
> libmap.conf, rather than by setting LD_LIBMAP_DISABLE in the
> build/installation environment, to avoid potential problems with
> sgid/suid binaries.

I don't think any suid/sgid app invoke gcc/ld during build. Besides,
libmap.conf won't affect gcc/ld because they're statically linked. OTOH,
smth like COMPILER_PATH=$LOCALBASE/bin has more chance breaking build in
an obscure way.

>
> Also, when updating or reinstalling ports, I would first deinstall the
> old versions (including old versions of the shared libraries that may
> be in *compat*) before rebuilding the new versions, to avoid any
> linking problems.

The order of paths in linker hints makes that unlikely. And direct
linking requires `-L' option anyway except for gcc specific libs.

> (We are still eagerly awaiting this or an equivalent
> sandbox "safe rebuild" option in ports-mgmt/portmaster. ;) )

I'd also like PATH overriding be put inside such a sandbox. While trying
to outsmart user portmaster makes using cc/ld wrappers harder.
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: "b. f." on 11 Jul 2010 23:01
On 7/11/10, Anonymous <swell.k(a)gmail.com> wrote:
> "b. f." <bf1783(a)googlemail.com> writes:

....

> Did you miss ports/148196? ld(1) ignores libmap.conf and will try to

I did miss it, but it doesn't really surprise me. I've only seen
discussion of libmap.conf(5) with reference to rtld(1), and AFAIK
ld(1) doesn't directly invoke rtld to find libraries during linking,
but instead performs it's own search, that only partially mimics rtld
(See comments in /usr/src/contrib/binutils/ld/emultempl/elf32.em).
The ld search seems to have been adapted from the vanilla GNU binutils
for FreeBSD in 1999, before libmap.conf was first added as an optional
hack of rtld for testing different threading libraries on FreeBSD in
2003. I suppose it's arguable that ld(1) should respect libmap.conf.
I haven't been troubled by this behavior because I don't rely on
libmap.conf -- I renumbered my gcc4*-related libraries and I use
-rpath directives.

> link from libs in /usr/lib before $LOCALBASE/lib if it can unless you
> alter linker hints. For any lib specified with `-l' I don't think even
> hints are used.

If they were, for anything other than the default base system search
directories, we would not be adding so many LDFLAGS in ports.

....

> I don't think any suid/sgid app invoke gcc/ld during build. Besides,
> libmap.conf won't affect gcc/ld because they're statically linked. OTOH,
> smth like COMPILER_PATH=$LOCALBASE/bin has more chance breaking build in
> an obscure way.

You are probably right about suid/sgid, but I prefer to sidestep the
issue entirely. I wasn't speculating as to the mechanism by which
remapping affected the build, only reporting that I had been shown
results where someone claimed that this was the case, in an otherwise
vanilla build. I cannot account for the differences -- perhaps that
person had really made some other changes that he had overlooked.

>> Also, when updating or reinstalling ports, I would first deinstall the
>> old versions (including old versions of the shared libraries that may
>> be in *compat*) before rebuilding the new versions, to avoid any
>> linking problems.
>
> The order of paths in linker hints makes that unlikely. And direct
> linking requires `-L' option anyway except for gcc specific libs.

Yes, but indirect doesn't, and many such problems have occurred in the
past, sometimes because of sloppy additions of -L.

b.
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

First  |  Prev  | 
Pages: 1 2 3
Prev: tabstop setting for port Makefiles
Next: nagios-plugins-1.4.14_1,1 Configure Error, libtool15 to blame