Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 13 Nov 2008 10:06:04 -0700
From:      John Hein <jhein@timing.com>
To:        ports@freebsd.org
Subject:   update from 6 to 7 - needs libtool rebuild
Message-ID:  <18716.24188.971858.627073@gromit.timing.com>

next in thread | raw e-mail | index | archive | help
I updated from 6-stable to 7-stable and got the following error
when portupgrading graphics/tiff...


 .
 .
/bin/sh /usr/local/bin/libtool --tag=CXX --mode=link c++   -O2 -fno-strict-aliasing -pipe  -L/usr/local/lib -o libtiffxx.la -rpath /usr/local/lib -no-undefined -version-number  4:0:0  tif_stream.lo ../libtiff/libtiff.la ../port/libport.la -ljpeg -lz -lm -lc
c++ -shared -nostdlib /usr/lib/crti.o /usr/lib/crtbeginS.o  .libs/tif_stream.o -Wl,--whole-archive ../port/.libs/libport.a -Wl,--no-whole-archive  -Wl,--rpath -Wl,/2/pub/jhein/.no-amanda-backup/wd/usr/ports/graphics/tiff/work/tiff-3.8.2/libtiff/.libs -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib -L/usr/local/lib ../libtiff/.libs/libtiff.so /usr/local/lib/libjpeg.so -lz -L/usr/lib -lstdc++ -lm -lgcc_pic /usr/lib/crtendS.o /usr/lib/crtn.o  -Wl,-soname -Wl,libtiffxx.so.4 -o .libs/libtiffxx.so.4
/usr/bin/ld: cannot find -lgcc_pic


As it turns out, a forced update of libtool was needed.

There are a few key differences between old libtool-1.15.26 from
6.x and the rebuilt one in 7.x

Below is just an excerpt of the diff.  Note the references to
i386-portbld-freebsd6.3 (in the old) and i386-portbld-freebsd7.1 (in
the new).  And the key for the issue reported above: lgcc_pic replaced
by lgcc_s.

[I'm not sure why the new lib search path has "/usr/lib /usr/lib"
 and later "-L/usr/lib -L/usr/lib", but that duplication is minor]

[ see also http://www.freebsd.org/cgi/query-pr.cgi?pr=113172 ]


So my question is: is this documented and/or widely known?  A full
portupgrade wouldn't help if you were up to date on libtool in 6.x
before updating (unless portupgrade -f is used).

If this isn't widely known, maybe this will help someone.

Would it be worth documenting this in UPDATING (if I haven't
missed it somewhere)?

I wonder if there's a good way to have this staleness on
OS update detected by our port/pkg update tools.


@@ -7387,13 +7387,13 @@
 
 # The host system.
 host_alias=
-host=i386-portbld-freebsd6.3
-host_os=freebsd6.3
+host=i386-portbld-freebsd7.1
+host_os=freebsd7.1
 
 # The build system.
-build_alias=i386-portbld-freebsd6.3
-build=i386-portbld-freebsd6.3
-build_os=freebsd6.3
+build_alias=i386-portbld-freebsd7.1
+build=i386-portbld-freebsd7.1
+build_os=freebsd7.1
 
 # An echo program that does not interpret backslashes.
 echo="echo"
@@ -7559,15 +7559,15 @@
 
 # Dependencies to place after the objects being linked to create a
 # shared library.
-postdeps="-lstdc++ -lm -lgcc_pic -lgcc_pic"
+postdeps="-lstdc++ -lm -lgcc_s -lc -lgcc_s"
 
 # The directories searched by this compiler when creating a shared
 # library
-compiler_lib_search_dirs="/usr/lib"
+compiler_lib_search_dirs="/usr/lib /usr/lib"
 
 # The library search path used internally by the compiler when linking
 # a shared library.
-compiler_lib_search_path="-L/usr/lib"
+compiler_lib_search_path="-L/usr/lib -L/usr/lib"
 
 # Method to check whether dependent libraries are shared objects.
 deplibs_check_method="pass_all"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18716.24188.971858.627073>