Date: Wed, 29 Mar 2006 20:32:50 +0200 From: Thomas-Martin Seck <tmseck-lists@netcologne.de> To: Dirk Meyer <dirk.meyer@dinoex.sub.org> Cc: freebsd-ports@freebsd.org Subject: Re: USE_GCC vs. packaging Message-ID: <20060329183250.GB2956@hardy.tmseck.homedns.org> In-Reply-To: <200603291801.k2TI1HLG021666@hardy.tmseck.homedns.org> References: <9FqyyWNhWW@dmeyer.dinoex.sub.org> <200603291801.k2TI1HLG021666@hardy.tmseck.homedns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[replying to myself] * Thomas-Martin Seck (tmseck-lists@netcologne.de): > * Dirk Meyer <dirk.meyer@dinoex.sub.org> [gmane.os.freebsd.devel.ports]: > > > Thomas-Martin Seck schrieb:, > > > >> A package built using this binary will fail unless libstc++.so.6 and > >> libgcc_s.so.1 are installed, too. > > > > They are installed. > > ldconfig could not find them. > > The problem is: this issue was introduced with the latest changes to > lang/gcc34. > > In short: > When I build a package of this port on 4.x with gcc 3.4.6 and install > this package on a vanilla 4.11 system, things will obviously blow up > since gcc 3.4.6 is not a registered dependency and libstdc++.so.6 is not > present there. pkg_add just does not know that it should pull in a gcc34 > package, too. And this is new, older versions of lang/gcc34 made it > possible that I could build a port using gcc34, build a package, take > this package to a vanilla system, install it there and run it without > installing gcc34 first to resolve libraries. > > This needs to be fixed, either by reverting the changes to gcc3X or by > changing USE_GCC in such a way that the gcc port used is made a build > and run dependency instead of a mere build dependency. What I think is different is that the linker now prefers lang/gcc*'s libstdc++ libraries over FreeBSD's "native" ones. With current lang/gcc34, this is what happens at build time when I build fltk2 on a vanilla 4.11 installation (in a chroot jail on a 6-STABLE host to be exact but this should not be the problem): ===> experimental-fltk-2.0.r4825 depends on executable: gmake - found ===> experimental-fltk-2.0.r4825 depends on executable: gcc34 - not found ===> Verifying package for gcc34 in /usr/ports/lang/gcc34 ===> Installing existing package /var/tmp/packages/All/gcc-3.4.6,1.tgz ===> Returning to build of experimental-fltk-2.0.r4825 ===> experimental-fltk-2.0.r4825 depends on shared library: png.5 - found ===> experimental-fltk-2.0.r4825 depends on shared library: jpeg.9 - found ===> experimental-fltk-2.0.r4825 depends on shared library: Xft.2 - found ===> experimental-fltk-2.0.r4825 depends on shared library: X11.6 - found ===> Configuring for experimental-fltk-2.0.r4825 checking for gcc... gcc34 checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc34 accepts -g... yes checking for gcc34 option to accept ANSI C... none needed checking whether we are using the GNU C++ compiler... yes checking whether g++34 accepts -g... yes ...snip... Libs: -lX11 -lXi -lXinerama -lXft -pthread -lm -lXext -lsupc++ System image libs: -lpng -ljpeg -lz Local image libs: OpenGL libs: -lGLU -lGL Build targets: static ===> Building for experimental-fltk-2.0.r4825 ...snip... Compiling cube.cxx... Linking cube... /usr/libexec/elf/ld: warning: libstdc++.so.3, needed by /usr/X11R6/lib/libGLU.so, may conflict with libstdc++.so.6 ^^^ This is new. Older versions of lang/gcc34 did not complain here. Linking statically with libfltk.a in turn causes a runtime dependency on libstc++.so.6 _for the application using fltk_ as shown in my first post on this topic. That is the problem I try to illustrate. This behaviour was introduced with the recent changes to lang/gcc34, older versions do not impose this dependency. As I said already, I checked with an older gcc34 package.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060329183250.GB2956>