Date: Mon, 12 Jul 2010 03:01:11 +0000 From: "b. f." <bf1783@googlemail.com> To: Anonymous <swell.k@gmail.com> Cc: Doug Barton <dougb@freebsd.org>, freebsd-ports@freebsd.org Subject: Re: graphics/png does not compile with gcc 4.5.1 Message-ID: <AANLkTinqr_1Vj8koHh1vojterWJtri-izNVBZB_pEpkr@mail.gmail.com> In-Reply-To: <86eifanipd.fsf@gmail.com> References: <AANLkTimUd-yh-HFsYTDZxP0XsdIywu2Oks0LY6Pz1lYS@mail.gmail.com> <86eifanipd.fsf@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/11/10, Anonymous <swell.k@gmail.com> wrote: > "b. f." <bf1783@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinqr_1Vj8koHh1vojterWJtri-izNVBZB_pEpkr>