Date: Wed, 5 May 2010 18:03:41 -0400 From: "b. f." <bf1783@googlemail.com> To: freebsd-gnome@FreeBSD.org Subject: Re: Grandfather dependencies completely out of control Message-ID: <r2vd873d5be1005051503j51789981hbe00a3ca6b6e2f4e@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Alexander Leidinger wrote: ,,, >Because of the libtool/pkg-config problem all childs of a >"problematic" lib will contain a reference to the lib, even if the >particular lib is just a dependency of a lib which the current port >uses. To make this description more explicit: if your port uses >libGRAPH (I made upt this name) and libGRAPH is linked to libjpeg and >libpng via libtool (at least 1.x), but your port is not directly using >symbols from libjpeg or libpng, the binaries of your port will have >libpng *and* libjpeg hardcoded. Use of LDFLAGS+= -Wl,--as-needed can help with this problem. But of course a lot of ports don't now respect LDFLAGS (many gnome ports offend in this regard). Because a lot of people want to use alternative compilers/toolchains for ports, and because of new gcc features like -flto, -fwhopr, and -fstack-protector* (the last has been enabled by default in the base system for some time now, but still cannot be properly used for a large number of ports which don't respect LDFLAGS), there needs to be a cleanup to ensure that as many ports as possible respect the toolchain (ADDR2LINE, AR, AS, CPPFILT, LD, NM, OBJCOPY, OBJDUMP, RANLIB, READELF, SIZE, STRINGS, STRIP) and compiler-related variables ( CC, CPP, CXX, CFLAGS, CPPFLAGS, CXXFLAGS, and LDFLAGS). b.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?r2vd873d5be1005051503j51789981hbe00a3ca6b6e2f4e>