graphics/png does not compile with gcc 4.5.1

[b. f.]

On 7/11/10, Anonymous <swell.k at gmail.com> wrote:
> "b. f." <bf1783 at 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.