Date: Mon, 26 Sep 2011 22:18:04 +0200 From: Rainer Hurling <rhurlin@gwdg.de> To: Chris Rees <crees@freebsd.org> Cc: freebsd-ports@freebsd.org, autotools@freebsd.org Subject: Re: Shared libs problem with ports under 10-CURRENT Message-ID: <4E80DDFC.2010005@gwdg.de> In-Reply-To: <CADLo83-BUBWP4qeMqe2dwfJnMsXFBhU3yq_avgKMS30OF3-XgQ@mail.gmail.com> References: <4E805A27.90106@gwdg.de> <CADLo83-BUBWP4qeMqe2dwfJnMsXFBhU3yq_avgKMS30OF3-XgQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Chris, On 26.09.2011 20:25 (UTC+2), Chris Rees wrote: > On 26 September 2011 11:55, Rainer Hurling<rhurlin@gwdg.de> wrote: >> This morning I tried to upgrade my ports after installing the new 10-CURRENT >> (amd64). >> >> Unfortunately now I am not able to build ports using shared libraries like >> ports/libXext any more. They only build .a and .la files, but not .so ones. >> >> Is it possible that there is something wrong now with libtool-2.4 (or the >> linker /usr/bin/ld)? >> >> #libtool --features >> host: amd64-portbld-freebsd10.0 >> disable shared libraries >> enable static libraries >> >> >> Does anyone else observes this behaviour? I would really appreciate some >> help. >> > > Excerpt from libtool configure script: > > dgux*) > archive_cmds='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags' > hardcode_libdir_flag_spec='-L$libdir' > hardcode_shlibpath_var=no > ;; > > freebsd1*) > ld_shlibs=no > ;; yes, this seems to be one problem. The configure script does not discriminate between FreeBSD version 1.* and 10.*. There are several places in the script, which should be corrected. After changing these and similar entries manually libtool gives #libtool --features host: amd64-portbld-freebsd10.0 enable shared libraries enable static libraries But there also must be another problem. When I try to rebuild the complete xorg-7.5.1 tree several libs where build without shared files (.so). libpng and libpython are built with shared libraries, the next port devel/pcre is built without shared libs, others follow. -r--r--r-- 1 root wheel - 173312 26 Sep 22:01:13 2011 libpng.so.6 lrwxr-xr-x 1 root wheel - 11 26 Sep 22:01:13 2011 libpng.so -> libpng.so.6 -r--r--r-- 1 root wheel - 259088 26 Sep 22:01:13 2011 libpng.a -r-xr-xr-x 1 root wheel - 2927606 26 Sep 22:04:39 2011 libpython2.7.a -r-xr-xr-x 1 root wheel - 1708416 26 Sep 22:05:31 2011 libpython2.7.so.1 lrwxr-xr-x 1 root wheel - 17 26 Sep 22:05:31 2011 libpython2.7.so -> libpython2.7.so.1 -rwxr-xr-x 1 root wheel - 904 26 Sep 22:09:08 2011 libpcreposix.la -rw-r--r-- 1 root wheel - 5350 26 Sep 22:09:08 2011 libpcreposix.a -rwxr-xr-x 1 root wheel - 898 26 Sep 22:09:08 2011 libpcrecpp.la -rw-r--r-- 1 root wheel - 59456 26 Sep 22:09:08 2011 libpcrecpp.a -rwxr-xr-x 1 root wheel - 863 26 Sep 22:09:08 2011 libpcre.la -rw-r--r-- 1 root wheel - 345458 26 Sep 22:09:08 2011 libpcre.a Thanks for answering. Rainer > # FreeBSD 2.2.[012] allows us to include c++rt0.o to get C++ constructor > # support. Future versions do this automatically, but an explicit c++rt0.o > # does not break anything, and helps significantly (at the cost of a little > # extra space). > freebsd2.2*) > > I've mentioned this to an autotools member, who has offered to fix it > fairly soon :) > > Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E80DDFC.2010005>