Mon 02 Mar 2009 06:44:14 AM UTC, comment #15:
There should be no problems building with any boost version. Please submit another bug report if there's still a problem with trunk or release branch.
|
Mon 27 Oct 2008 07:14:08 PM UTC, comment #14:
DEFAULT_STREAMS_TIMEOUT and SYSCONFDIR should be defined after running autogen.sh and configure.
|
Mon 27 Oct 2008 07:08:57 PM UTC, comment #13:
I don't know. I don't even get there:
../../libbase/rc.cpp: In constructor 'gnash::RcInitFile::RcInitFile()':
../../libbase/rc.cpp:94: error: 'DEFAULT_STREAMS_TIMEOUT' was not declared in this scope
../../libbase/rc.cpp: In member function 'void gnash::RcInitFile::loadFiles()':
../../libbase/rc.cpp:131: error: 'SYSCONFDIR' was not declared in this scope
|
Sun 26 Oct 2008 03:33:17 PM UTC, comment #12:
Is this still a bug?
|
Mon 07 Apr 2008 04:32:04 PM UTC, comment #11:
emerge -uD world
That's the ultimate update command. You will probably want to use --pretend first to check that it doesn't do something stupid.
|
Mon 07 Apr 2008 02:54:57 PM UTC, comment #10:
After doing an emerge --sync, nothing links for me anymore, so I'll have to fix that problem first, and then see what's happening. The linker errors I'm not getting have nothing to do with Boost at all, so I have to see what changed. I did modify configure to remove the -s appended by Gentoo to the library name, but have other issues with GCC 4.1.1 that I can't work around just yet. 4.1.1 sucked and has other linker issues on a variety of platforms, I prefer GCC 4.2.x myself.
As far as I can tell, this problem is Gentoo specific. Is there a way I can force my entire gentoo system to update itself to try to fix the other linker issues I'm having now ?
|
Sun 06 Apr 2008 08:56:59 PM UTC, comment #9:
The problem is not that it doesn't find them. The problem is that these are the static libraries, which are not compiled with -fPIC and thus fail to link when building shared objects.
|
Sun 06 Apr 2008 06:43:20 PM UTC, comment #8:
Ok, I emerged Boost up to 1.34.1, and configure found the libraries just fine. You can see for me if found them with the -s on the end of the name.
BOOST libs are: -L/usr/lib64 -lboost_thread-mt-s -lboost_date_time-mt-s
BOOST Extra libs are: -lboost_serialization-mt-s
|
Sat 05 Apr 2008 09:31:08 PM UTC, comment #7:
That worked, it's building boost 34 now.
|
Sat 05 Apr 2008 09:19:20 PM UTC, comment #6:
In that case, you have to unmerge the old version explicitly first.
# emerge --unmerge boost
# emerge -av1 boost
|
Sat 05 Apr 2008 09:13:11 PM UTC, comment #5:
So I get this when I try to emerge boost
[blocks B ] <dev-libs/boost-1.34.0 (is blocking dev-util/boost-build-1.34.1)
I did the emerge --sync step first.
|
Sat 05 Apr 2008 07:56:29 PM UTC, comment #4:
My version is marked stable, and my last tree sync was several days ago. So
# emerge --sync
# emerge -av1 boost
ought to upgrade. You can also try
# emerge -av1 ">=dev-libs/boost-1.34"
to force Boost 1.34 or higher. If the ebuild is merely masked, it would tell you so. You could then unmask it using
# echo "=dev-libs/boost-1.34.1* ~amd64" >> /etc/portage/package.keywords
|
Sat 05 Apr 2008 07:49:20 PM UTC, comment #3:
Can I force emerge to upgrade ? I'm running a pretty stock gentoo system, but emerge says 1.33.1 is the latest. I'm not a very experienced gentoo user. If I can upgrade, I can fix configure to do the right thing. The boost library naming convention is so silly.
|
Sat 05 Apr 2008 07:46:10 PM UTC, comment #2:
I have boost-1.34.1-r2 installed. That would be the most obvious difference.
|
Sat 05 Apr 2008 01:58:20 PM UTC, comment #1:
Well, on my x86_64 Gentoo system, the boost libraries aren't named this way, so Gnash builds just fine for me with the default compiler. With Boost 1.33.1 on my Gentoo system, I don't even see any static libraries at all, and configure works just fine.I can easily fix configure to do the right thing, but first we;d have to figure out why my installation differs from yours.
|
Sat 05 Apr 2008 10:56:06 AM UTC, original submission:
On Gentoo systems (and perhaps elsewhere, too), Boost is installed using the system layout. One effect of this is that the static libraries are called libboost_-s.a and the dynamic libraries are called libboost_.so. Note the -s suffix for the static library name.
Gnash's Boost library detection mechanism is very simple. It uses the equivalent of `ls ${LIBDIR}/libboost_${libname}*.{a,so}` to enumerate all possible candidates for the libraries and then uses sed to extract the basename of the first of these.
Due to the way the list is constructed, the first library happens to be a static variant, i.e. the resulting basename is boost_libname-s. Thus, the makefiles are configured to pass -lboost_libname-s to the compiler, for both the static and the dynamic build.
The static versions of the Boost libraries are not built with the -fPIC flag. On x86-64, object files going into shared objects must be built with the -fPIC flag, or linking fails.
This is just what happens, though, because the linker gets the static Boost libraries as input for linking libgnashbase-cvs.so.
Thus, the following compile error:
make[2]: Entering directory `/home/wasti/projects/gnash/build/libbase'
/bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -pthread -pthread -W -Wall -Wcast-align -Wcast-qual -Wpointer-arith -Wreturn-type -fvisibility-inlines-hidden -release cvs -Wl,--as-needed -o libgnashbase.la -rpath /usr/local/lib/gnash libgnashbase_la-extension.lo libgnashbase_la-image.lo libgnashbase_la-jpeg.lo libgnashbase_la-log.lo libgnashbase_la-memory.lo libgnashbase_la-rc.lo libgnashbase_la-shm.lo libgnashbase_la-sharedlib.lo libgnashbase_la-string_table.lo libgnashbase_la-tu_file.lo libgnashbase_la-tu_timer.lo libgnashbase_la-WallClockTimer.lo libgnashbase_la-utf8.lo libgnashbase_la-utility.lo libgnashbase_la-curl_adapter.lo libgnashbase_la-noseek_fd_adapter.lo libgnashbase_la-zlib_adapter.lo libgnashbase_la-URL.lo libgnashbase_la-LoadThread.lo libgnashbase_la-FLVParser.lo libgnashbase_la-GC.lo libgnashbase_la-BitsReader.lo libgnashbase_la-arg_parser.lo -ljpeg -L/lib -lz -L/usr/lib64 -lcurl -lltdl -L/usr/lib64 -lboost_thread-mt-s -lboost_date_time-mt-s -lpthread -lc -lrt -lX11 -lXi -lm
g++ -shared -nostdlib /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/crtbeginS.o .libs/libgnashbase_la-extension.o .libs/libgnashbase_la-image.o .libs/libgnashbase_la-jpeg.o .libs/libgnashbase_la-log.o .libs/libgnashbase_la-memory.o .libs/libgnashbase_la-rc.o .libs/libgnashbase_la-shm.o .libs/libgnashbase_la-sharedlib.o .libs/libgnashbase_la-string_table.o .libs/libgnashbase_la-tu_file.o .libs/libgnashbase_la-tu_timer.o .libs/libgnashbase_la-WallClockTimer.o .libs/libgnashbase_la-utf8.o .libs/libgnashbase_la-utility.o .libs/libgnashbase_la-curl_adapter.o .libs/libgnashbase_la-noseek_fd_adapter.o .libs/libgnashbase_la-zlib_adapter.o .libs/libgnashbase_la-URL.o .libs/libgnashbase_la-LoadThread.o .libs/libgnashbase_la-FLVParser.o .libs/libgnashbase_la-GC.o .libs/libgnashbase_la-BitsReader.o .libs/libgnashbase_la-arg_parser.o /usr/lib64/libjpeg.so -L/lib -lz -L/usr/lib64 /usr/lib64/libcurl.so /usr/lib64/libltdl.so -lboost_thread-mt-s -lboost_date_time-mt-s -lpthread -lrt /usr/lib64/libX11.so /usr/lib64/libXi.so -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/../../../../lib64/crtn.o -pthread -pthread -Wl,--as-needed -Wl,-soname -Wl,libgnashbase-cvs.so -o .libs/libgnashbase-cvs.so
/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libboost_thread-mt-s.a(mutex.o): relocation R_X86_64_32 against `boost::thread_resource_error::~thread_resource_error()' can not be used when making a shared object; recompile with -fPIC
/usr/lib64/libboost_thread-mt-s.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [libgnashbase.la] Error 1
make[2]: Leaving directory `/home/wasti/projects/gnash/build/libbase'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/wasti/projects/gnash/build'
make: *** [all] Error 2
I'm not sure what to do about this. Changing the configure test to pick up the shared library instead is a possible hack, but it would make the static build not be static anymore. You'd have to configure it so that libtool gives different flags to the shared and the static build, and I don't know anything about libtool.
|