Re: gnash-0.8.3: build fails on 6.3
on 04/07/2008 15:36 Andriy Gapon said the following: > on 04/07/2008 01:34 Dmitry Marakasov said the following: >> * Andriy Gapon ([EMAIL PROTECTED]) wrote: >> >>> A s we can see -L/usr/lib comes before gcc-4.2.4 path and thus base >>> libstdc+ is picked over the correct one. >>> >>> Since you can not reproduce this in clean environment I wonder where >>> that -L/usr/lib comes from. >> Seems like you're right, I don't have -L/usr/lib in gcc args when >> building gnash. >> >> Could you please send me conf* files from the workdir (config.log etc.) >> and all Makefile* files (Makefile, Makefile.in from all subdirs). >> > > Dmitry, > > I decided to do some more local research before sending you that bulk data. > > Here's what I have so far. > 1. There is no -L/usr/lib in the corresponding libtool invocation, so it > means that libtool itself adds it. > 2. There is the following line in libtool script (in gnash base dir): > sys_lib_search_path_spec=" /usr/lib/" > 3. In configure script I see that is set based on $CC -print-search-dirs > 4. gcc42 -print-search-dirs produces "good" list of directories where > its specific directories precede /usr/lib. > 5. But gcc -print-search-dirs produces only /usr/lib. This may seem a quite strange question - do you have fortran of base GCC (f77) installed in your tinderbox? -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gnash-0.8.3: build fails on 6.3
on 04/07/2008 01:34 Dmitry Marakasov said the following: > * Andriy Gapon ([EMAIL PROTECTED]) wrote: > >> A s we can see -L/usr/lib comes before gcc-4.2.4 path and thus base >> libstdc+ is picked over the correct one. >> >> Since you can not reproduce this in clean environment I wonder where >> that -L/usr/lib comes from. > Seems like you're right, I don't have -L/usr/lib in gcc args when > building gnash. > > Could you please send me conf* files from the workdir (config.log etc.) > and all Makefile* files (Makefile, Makefile.in from all subdirs). > Dmitry, I decided to do some more local research before sending you that bulk data. Here's what I have so far. 1. There is no -L/usr/lib in the corresponding libtool invocation, so it means that libtool itself adds it. 2. There is the following line in libtool script (in gnash base dir): sys_lib_search_path_spec=" /usr/lib/" 3. In configure script I see that is set based on $CC -print-search-dirs 4. gcc42 -print-search-dirs produces "good" list of directories where its specific directories precede /usr/lib. 5. But gcc -print-search-dirs produces only /usr/lib. -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gnash-0.8.3: build fails on 6.3
* Andriy Gapon ([EMAIL PROTECTED]) wrote: > A s we can see -L/usr/lib comes before gcc-4.2.4 path and thus base > libstdc+ is picked over the correct one. > > Since you can not reproduce this in clean environment I wonder where > that -L/usr/lib comes from. Seems like you're right, I don't have -L/usr/lib in gcc args when building gnash. Could you please send me conf* files from the workdir (config.log etc.) and all Makefile* files (Makefile, Makefile.in from all subdirs). -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D [EMAIL PROTECTED] ..: jabber: [EMAIL PROTECTED]http://www.amdmi3.ru ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gnash-0.8.3: build fails on 6.3
on 03/07/2008 20:46 Andriy Gapon said the following: > Now an important finding - it seems that g++42 tries to use different > libstdc++, not its own. > I verified with nm that missing symbols are present in > /usr/local/lib/gcc-4.2.4/libstdc++.so.6, but g++42 doesn't see them. > I explicitly added the library to command line and then linking succeeded. > I am quite puzzled as to why g++42 would not see its own libstdc++ or > prefer other libstdc++ over its own. > Might this be because of -L/usr/lib in the command line? Seems so - I added -v flag tp g++42 linking invocation and here's a snippet from output: /usr/local/libexec/gcc/x86_64-portbld-freebsd6.3/4.2.4/collect2 -V -dynamic-linker /libexec/ld-elf.so.1 -o .libs/gprocessor /usr/lib/crt1.o /usr/lib/crti.o /usr/local/lib/gcc-4.2.4/gcc/x86_64-portbld-freebsd6.3/4.2.4/crtbegin.o -L/usr/local/lib -L/usr/lib -L/usr/X11R6/lib -L/usr/local/lib/gcc-4.2.4/gcc/x86_64-portbld-freebsd6.3/4.2.4 -L/usr/local/lib/gcc-4.2.4/gcc/x86_64-portbld-freebsd6.3/4.2.4/../../.. /usr/local/lib/libintl.so /usr/local/lib/libiconv.so -rpath ... A s we can see -L/usr/lib comes before gcc-4.2.4 path and thus base libstdc+ is picked over the correct one. Since you can not reproduce this in clean environment I wonder where that -L/usr/lib comes from. -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gnash-0.8.3: build fails on 6.3
on 01/07/2008 22:36 Dmitry Marakasov said the following: > * Andriy Gapon ([EMAIL PROTECTED]) wrote: > > Any news on the problem? I've gon 2 more reports of gnash failure on > 6.3. I've tried to reproduce bug in 6.3 jail, but with no luck (tried > rebuilding everything with different suspicios options that may affect > gnash or ports it depends on (WITH_OPTIMIZED_CFLAGS, WITHOUT_DEBUG), > also tried to build everything when multiple versions of gcc are present > - it just builds without problems. I also tried clean re-install (as opposed to upgrade via portupgrade) and that resulted in the same error. > Could you please mail me your make.conf and `pkg_info` output? Let me send those a bit later. Now an important finding - it seems that g++42 tries to use different libstdc++, not its own. I verified with nm that missing symbols are present in /usr/local/lib/gcc-4.2.4/libstdc++.so.6, but g++42 doesn't see them. I explicitly added the library to command line and then linking succeeded. I am quite puzzled as to why g++42 would not see its own libstdc++ or prefer other libstdc++ over its own. Might this be because of -L/usr/lib in the command line? BTW, I have the following GCCs installed: gcc-4.2.4_20080430 gcc-4.3.2_20080626 gcc-ooo-3.4.1_3 Plus base GCC 3.4.6. And their libs: /usr/lib/libstdc++.so /usr/lib/libstdc++.so.5 /usr/lib32/libstdc++.so /usr/lib32/libstdc++.so.5 /usr/local/lib/gcc-4.2.4/libstdc++.so /usr/local/lib/gcc-4.2.4/libstdc++.so.6 /usr/local/lib/gcc-4.3.2/libstdc++.so /usr/local/lib/gcc-4.3.2/libstdc++.so.6 -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gnash-0.8.3: build fails on 6.3
* Andriy Gapon ([EMAIL PROTECTED]) wrote: Any news on the problem? I've gon 2 more reports of gnash failure on 6.3. I've tried to reproduce bug in 6.3 jail, but with no luck (tried rebuilding everything with different suspicios options that may affect gnash or ports it depends on (WITH_OPTIMIZED_CFLAGS, WITHOUT_DEBUG), also tried to build everything when multiple versions of gcc are present - it just builds without problems. Could you please mail me your make.conf and `pkg_info` output? -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D [EMAIL PROTECTED] ..: jabber: [EMAIL PROTECTED]http://www.amdmi3.ru ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gnash-0.8.3: build fails on 6.3
on 24/06/2008 19:51 Dmitry Marakasov said the following: > * Andriy Gapon ([EMAIL PROTECTED]) wrote: >> System: FreeBSD 6.3-RELEASE amd64 >> Build of port graphics/gnash fails at link stage: >> ... >> >> It seems like there is an unsatisfied symbol in boost library that was >> supposed to come from standard C++ library. >> I see that gnash is compiled with GCC 4.2+, but I think that boost is >> compiled with default GCC for 6.3 which is 3.4.6. >> I suspect that the error might be caused by this mismatch in versions. >> This should not be a problem on 7.0 where default GCC is 4.2.X, but 6.3 >> is still a "stabler stable" for me. > Hi! > > Hmm... It seems to be related to library versions, yes, but I think > it's most likely a local problem. I've tested gnash on FreeBSD 6.3 > amd64 in tinderbox and it built without problems. Packages were > build successfully on pointyhat as well > (http://portsmon.freebsd.org/portoverview.py?category=graphics&portname=gnash). > Besides, you're the first one who reports such problem. I guess the reason might be that I built boost with OPTIMIZED_CFLAGS enabled. In fact I have WITH_OPTIMIZED_CFLAGS in my make.conf. > You can use precompiled packages for gnash instead (I can build a > package for you in a tinderbox if you need any nondefault options), > otherwise I don't think I can help since I cannot reproduce this at > least in a jail. You could also try rebuilding boost. Rebuilding boost didn't help. I'll try to rebuild without the optimization flags later. Thank you for offering your help, but I'd like to get a sustainable solution, if possible. -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gnash-0.8.3: build fails on 6.3
* Andriy Gapon ([EMAIL PROTECTED]) wrote: > > System: FreeBSD 6.3-RELEASE amd64 > Build of port graphics/gnash fails at link stage: > ... > > It seems like there is an unsatisfied symbol in boost library that was > supposed to come from standard C++ library. > I see that gnash is compiled with GCC 4.2+, but I think that boost is > compiled with default GCC for 6.3 which is 3.4.6. > I suspect that the error might be caused by this mismatch in versions. > This should not be a problem on 7.0 where default GCC is 4.2.X, but 6.3 > is still a "stabler stable" for me. Hi! Hmm... It seems to be related to library versions, yes, but I think it's most likely a local problem. I've tested gnash on FreeBSD 6.3 amd64 in tinderbox and it built without problems. Packages were build successfully on pointyhat as well (http://portsmon.freebsd.org/portoverview.py?category=graphics&portname=gnash). Besides, you're the first one who reports such problem. You can use precompiled packages for gnash instead (I can build a package for you in a tinderbox if you need any nondefault options), otherwise I don't think I can help since I cannot reproduce this at least in a jail. You could also try rebuilding boost. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D [EMAIL PROTECTED] ..: jabber: [EMAIL PROTECTED]http://www.amdmi3.ru ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gnash-0.8.3: build fails on 6.3
System: FreeBSD 6.3-RELEASE amd64 Build of port graphics/gnash fails at link stage: ... Making all in utilities gmake[2]: Entering directory `/usr/ports/graphics/gnash/work/gnash-0.8.3/utilities' /bin/sh ../libtool --tag=CXX --mode=link g++42 -O2 -fno-strict-aliasing -pipe -O2 -fno-strict-aliasing -pipe -march=athlon64 -O2 -fno-strict-aliasing -pipe -pthread -D_THREAD_SAFE -pthread -W -Wall -Wcast-align -Wcast-qual -Wpointer-arith -Wreturn-type -fvisibility-inlines-hidden -export-dynamic -lltdl -L/usr/local/lib -lxml2 -lz -L/usr/local/lib -liconv -lm -L/usr/local/lib -lcurl -L/usr/local/lib -lboost_thread -lboost_date_time -lpthread /usr/local/lib/libintl.so /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib -L/usr/local/lib -Wl,--as-needed -o gprocessor gprocessor-processor.o ../server/libgnashserver.la ../libamf/libgnashamf.la ../libnet/libgnashnet.la ../libbase/libgnashbase.la ../libmedia/libgnashmedia.la -lavcodec -lz -la52 -lfaad -lx264 -ltheora -lvorbisenc -lavutil -lvorbis -lm -logg -ldca -lvorbisenc -lvorbis -lm -logg -lavformat -lavcodec -lz -la52 -lfaad -lx264 -ltheora -lvorbisenc -lavutil -lvorbis -lm -logg -lavutil -ltheora -logg -lgsm -lavcodec -lz -la52 -lfaad -lx264 -ltheora -lvorbisenc -lavutil -lvorbis -lm -logg-L/usr/local/lib -lglib-2.0 -liconv -lX11 -lXi -lm g++42 -O2 -fno-strict-aliasing -pipe -O2 -fno-strict-aliasing -pipe -march=athlon64 -O2 -fno-strict-aliasing -pipe -pthread -D_THREAD_SAFE -pthread -W -Wall -Wcast-align -Wcast-qual -Wpointer-arith -Wreturn-type -fvisibility-inlines-hidden /usr/local/lib/libintl.so /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib -Wl,--as-needed -o .libs/gprocessor gprocessor-processor.o -Wl,--export-dynamic -L/usr/local/lib -L/usr/lib ../server/.libs/libgnashserver.so -L/usr/X11R6/lib /usr/ports/graphics/gnash/work/gnash-0.8.3/libnet/.libs/libgnashnet.so /usr/ports/graphics/gnash/work/gnash-0.8.3/libmedia/.libs/libgnashmedia.so /usr/local/lib/libfontconfig.so /usr/local/lib/libfreetype.so /usr/local/lib/libexpat.so ../libamf/.libs/libgnashamf.so ../libnet/.libs/libgnashnet.so /usr/ports/graphics/gnash/work/gnash-0.8.3/libamf/.libs/libgnashamf.so /usr/ports/graphics/gnash/work/gnash-0.8.3/libbase/.libs/libgnashbase.so /usr/local/lib/libxml2.so ../libbase/.libs/libgnashbase.so ../libmedia/.libs/libgnashmedia.so /usr/local/lib/libjpeg.so /usr/local/lib/libcurl.so /usr/local/lib/libcares.so /usr/local/lib/libssh2.so -lssl -lcrypto /usr/local/lib/libltdl.so -lboost_thread -lboost_date_time -lpthread /usr/local/lib/libSDL.so /usr/local/lib/libXrandr.so /usr/local/lib/libXrender.so /usr/local/lib/libggi.so /usr/X11R6/lib/libXxf86vm.so /usr/local/lib/libgii.so /usr/local/lib/libXxf86dga.so /usr/local/lib/libgg.so /usr/local/lib/libaa.so -lncurses -lusbhid /usr/local/lib/libdca.so -lavformat -lgsm -lavcodec -lz /usr/local/lib/liba52.so -ldjbfft /usr/local/lib/libfaad.so -pthread -lx264 /usr/local/lib/libtheora.so /usr/local/lib/libvorbisenc.so -lavutil /usr/local/lib/libvorbis.so /usr/local/lib/libogg.so /usr/local/lib/libglib-2.0.so /usr/local/lib/libintl.so /usr/local/lib/libpcre.so /usr/local/lib/libiconv.so /usr/local/lib/libXi.so /usr/X11R6/lib/libXext.so /usr/local/lib/libX11.so /usr/local/lib/libXdmcp.so -lrpcsvc /usr/local/lib/libXau.so -lm -Wl,--rpath -Wl,/usr/local/lib/gnash -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/X11R6/lib gprocessor-processor.o(.gnu.linkonce.t._ZN5boost2io6detail3putIcSt11char_traitsIcESaIcERKlEEvT2_RKNS1_11format_itemIT_T0_T1_EERNS_12basic_formatISA_SB_SC_E11string_typeERNSH_20internal_streambuf_tEPSt6locale+0x1c2): In function `void boost::io::detail::put, std::allocator, long const&>(long const&, boost::io::detail::format_item, std::allocator > const&, boost::basic_format, std::allocator >::string_type&, boost::basic_format, std::allocator >::internal_streambuf_t&, std::locale*)': : undefined reference to `std::basic_ostream >& std::basic_ostream >::_M_insert(long)' ... It seems like there is an unsatisfied symbol in boost library that was supposed to come from standard C++ library. I see that gnash is compiled with GCC 4.2+, but I think that boost is compiled with default GCC for 6.3 which is 3.4.6. I suspect that the error might be caused by this mismatch in versions. This should not be a problem on 7.0 where default GCC is 4.2.X, but 6.3 is still a "stabler stable" for me. -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
