Re: Handling object name conflicts
Ralf Wildenhues wrote: Hi Peter, * Peter O'Gorman wrote on Sat, May 28, 2005 at 05:56:03PM CEST: Ralf Wildenhues wrote: What happens instead with your patch applied (sorry for not checking myself)? Attached is a gnuradio build snippit. Also passes all tests. That looks fine, yes. Thanks! I just applied this patch to all branches. Peter -- Peter O'Gorman - http://www.pogma.com Index: ChangeLog 2004-05-31 Peter O'Gorman [EMAIL PROTECTED] * ltmain.in: Do not add installed static litool libraries to convenience, they are not convenience libraries. Reported by Chen-Mou Cheng [EMAIL PROTECTED] from Ralf Wildenhues [EMAIL PROTECTED] Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v retrieving revision 1.334.2.69 diff -u -3 -p -u -r1.334.2.69 ltmain.in --- ltmain.in 4 May 2005 13:52:10 - 1.334.2.69 +++ ltmain.in 31 May 2005 03:46:21 - @@ -2729,8 +2729,6 @@ EOF fi fi else - convenience=$convenience $dir/$old_library - old_convenience=$old_convenience $dir/$old_library deplibs=$dir/$old_library $deplibs link_static=yes fi ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Handling object name conflicts
Hi Peter, * Peter O'Gorman wrote on Sat, May 28, 2005 at 05:56:03PM CEST: Ralf Wildenhues wrote: What happens instead with your patch applied (sorry for not checking myself)? Attached is a gnuradio build snippit. Also passes all tests. That looks fine, yes. Thanks! Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Handling object name conflicts
Chen-Mou Cheng wrote: Yes it happens with released version as well. Can you confirm that the attached patch to ltmain.sh fixes this issue for you? Thanks, Peter -- Peter O'Gorman - http://www.pogma.com --- ltmain.sh~ Mon May 16 18:39:29 2005 +++ ltmain.sh Sat May 28 07:38:05 2005 @@ -2729,8 +2729,6 @@ fi fi else - convenience=$convenience $dir/$old_library - old_convenience=$old_convenience $dir/$old_library deplibs=$dir/$old_library $deplibs link_static=yes fi ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Handling object name conflicts
On 5/27/05, Peter O'Gorman [EMAIL PROTECTED] wrote: Can you confirm that the attached patch to ltmain.sh fixes this issue for you? Thanks, Peter -- Peter O'Gorman - http://www.pogma.com --- ltmain.sh~ Mon May 16 18:39:29 2005 +++ ltmain.sh Sat May 28 07:38:05 2005 @@ -2729,8 +2729,6 @@ fi fi else - convenience=$convenience $dir/$old_library - old_convenience=$old_convenience $dir/$old_library deplibs=$dir/$old_library $deplibs link_static=yes fi Yes it does fix the problem. That's awesome. Would you like to explain briefly why it fixed the problem? Thanks, Chen-Mou ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Handling object name conflicts
Hi Ralf, On 5/20/05, Ralf Wildenhues [EMAIL PROTECTED] wrote: * Chen-Mou Cheng wrote on Fri, May 20, 2005 at 06:29:28AM CEST: On 5/19/05, Peter O'Gorman [EMAIL PROTECTED] wrote: Chen-Mou Cheng wrote: | | I have noticed that from 1.5.14 to 1.5.16, the way of handling object | name conflicts has been changed from renaming conflicting files to | just exiting with an ERROR (see the relevant diff fragment attached | below). I am having problems with 1.5.16 in building gnuradio; it | breaks when gnuradio is trying to link against libfft3w, which | contains objects of same names. But when I go back to 1.5.14, it | builds successfully. Can somebody explain to me whether this is | gnuradio/libfft3w's fault, or it is simply a libtool-1.5.16's bug? | Thanks! This change should only have affected convenience libraries. Is libfft3w a gnuradio convenience library? If so you should rebuild it. There is new code when making a convenience library that ensures there are no duplicated member names. Thanks for the prompt response. I am not sure what you mean by a convenience library; libfft3w is a separate project from gnuradio (and they are installed separately). However when building gnuradio, the static library /usr/local/lib/libfft3w.a is first extracted in a .lib directory under gnuradio's source tree. Then the object files are linked against libgnuradio; it is in this process the new libtool breaks. Please show the libtool link line and all output it generates (copy and paste). Please also show the relevant Makefile.am snippet that describes the library you link, if any. This way, it might be possible to decide whether this is a libtool bug or not. BTW, you meant libfftw3, not libfft3w, right? The former is not a library FFTW generates, AFAIK. Indeed, I meant libfftw3; sorry about the typo and the confusion. Below is the libtool line and the output it generated: /bin/sh ../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall -Woverloaded-virtual-o libgnuradio-core.la -rpath /usr/local/lib -no-undefined -version-info 0:0:0 bug_work_around_6.lo filter/libfilter.la g72x/libccitt.la general/libgeneral.la io/libio.la missing/libmissing.la omnithread/libomnithread.la reed-solomon/librs.la runtime/libruntime.la -L/usr/local/lib -lcppunit -ldl -L/usr/local/lib -lfftw3f -lm rm -fr .libs/libgnuradio-core.lax mkdir .libs/libgnuradio-core.lax rm -fr .libs/libgnuradio-core.lax/libfilter.a mkdir .libs/libgnuradio-core.lax/libfilter.a Extracting /Users/doug/gr-build/gnuradio-core/src/lib/filter/.libs/libfilter.a (cd .libs/libgnuradio-core.lax/libfilter.a ar x /Users/doug/gr-build/gnuradio-core/src/lib/filter/.libs/libfilter.a) rm -fr .libs/libgnuradio-core.lax/libccitt.a mkdir .libs/libgnuradio-core.lax/libccitt.a Extracting /Users/doug/gr-build/gnuradio-core/src/lib/g72x/.libs/libccitt.a (cd .libs/libgnuradio-core.lax/libccitt.a ar x /Users/doug/gr-build/gnuradio-core/src/lib/g72x/.libs/libccitt.a) rm -fr .libs/libgnuradio-core.lax/libgeneral.a mkdir .libs/libgnuradio-core.lax/libgeneral.a Extracting /Users/doug/gr-build/gnuradio-core/src/lib/general/.libs/libgeneral.a (cd .libs/libgnuradio-core.lax/libgeneral.a ar x /Users/doug/gr-build/gnuradio-core/src/lib/general/.libs/libgeneral.a) rm -fr .libs/libgnuradio-core.lax/libio.a mkdir .libs/libgnuradio-core.lax/libio.a Extracting /Users/doug/gr-build/gnuradio-core/src/lib/io/.libs/libio.a (cd .libs/libgnuradio-core.lax/libio.a ar x /Users/doug/gr-build/gnuradio-core/src/lib/io/.libs/libio.a) rm -fr .libs/libgnuradio-core.lax/libmissing.a mkdir .libs/libgnuradio-core.lax/libmissing.a Extracting /Users/doug/gr-build/gnuradio-core/src/lib/missing/.libs/libmissing.a (cd .libs/libgnuradio-core.lax/libmissing.a ar x /Users/doug/gr-build/gnuradio-core/src/lib/missing/.libs/libmissing.a) rm -fr .libs/libgnuradio-core.lax/libomnithread.a mkdir .libs/libgnuradio-core.lax/libomnithread.a Extracting /Users/doug/gr-build/gnuradio-core/src/lib/omnithread/.libs/libomnithread.a (cd .libs/libgnuradio-core.lax/libomnithread.a ar x /Users/doug/gr-build/gnuradio-core/src/lib/omnithread/.libs/libomnithread.a) rm -fr .libs/libgnuradio-core.lax/librs.a mkdir .libs/libgnuradio-core.lax/librs.a Extracting /Users/doug/gr-build/gnuradio-core/src/lib/reed-solomon/.libs/librs.a (cd .libs/libgnuradio-core.lax/librs.a ar x /Users/doug/gr-build/gnuradio-core/src/lib/reed-solomon/.libs/librs.a) rm -fr .libs/libgnuradio-core.lax/libruntime.a mkdir .libs/libgnuradio-core.lax/libruntime.a Extracting /Users/doug/gr-build/gnuradio-core/src/lib/runtime/.libs/libruntime.a (cd .libs/libgnuradio-core.lax/libruntime.a ar x /Users/doug/gr-build/gnuradio-core/src/lib/runtime/.libs/libruntime.a) rm -fr .libs/libgnuradio-core.lax/libfftw3f.a mkdir .libs/libgnuradio-core.lax/libfftw3f.a Extracting /usr/local/lib/libfftw3f.a (cd .libs/libgnuradio-core.lax/libfftw3f.a ar x /usr/local/lib/libfftw3f.a) libtool: link: ERROR
Re: Handling object name conflicts
On 5/19/05, Peter O'Gorman [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chen-Mou Cheng wrote: | Hi, | | I have noticed that from 1.5.14 to 1.5.16, the way of handling object | name conflicts has been changed from renaming conflicting files to | just exiting with an ERROR (see the relevant diff fragment attached | below). I am having problems with 1.5.16 in building gnuradio; it | breaks when gnuradio is trying to link against libfft3w, which | contains objects of same names. But when I go back to 1.5.14, it | builds successfully. Can somebody explain to me whether this is | gnuradio/libfft3w's fault, or it is simply a libtool-1.5.16's bug? | Thanks! | This change should only have affected convenience libraries. Is libfft3w a gnuradio convenience library? If so you should rebuild it. There is new code when making a convenience library that ensures there are no duplicated member names. Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQo1RHriDAg3OZTLPAQK/KwP/ZeyYtRnAqk7a5Ybd5E2yNMId3r5LTOCo QQ7UxOqxO3P5oMxPrJgvtColpScVHZ6lvsu5Jw2YVz0KkO+SWcAGkKrVBg6w58ZB MQNt5X1HvryqWD4NIdI61mrvtQ0J4QBnNqUlITrgaXjZ/z9/+1GbAs85zpBuvOrj bRq0jUJ61n0= =BJl0 -END PGP SIGNATURE- Hi Peter, Thanks for the prompt response. I am not sure what you mean by a convenience library; libfft3w is a separate project from gnuradio (and they are installed separately). However when building gnuradio, the static library /usr/local/lib/libfft3w.a is first extracted in a .lib directory under gnuradio's source tree. Then the object files are linked against libgnuradio; it is in this process the new libtool breaks. Are you saying that this build process is no longer supported by libtool, and that gnuradio should use this new code instead of libtool? Thanks, Chen-Mou ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
