Re: Making shared libraries (DLLs) on Windows: -no-undefined
Brian Dessent wrote: So yes, you need to either use -no-undefined unconditionally, or conditionalized on PE targets. What's the point of doing this only on PE targets? Surely the library will either have undefined symbols or not, independent of target... (and note that Windows is not the only platform that needs -no-undefined for shared libraries) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool / SkyOS / ELF
Ralf Wildenhues wrote: I think that should be possible. But of course, that will limit the ways in which you will be able to upgrade your shared libraries later. Also, since I think version_type=none may not have seen so much usage exposure in Libtool, there may have been bit rot. There's still the problem of http://article.gmane.org/gmane.comp.gnu.libtool.general/7325 AFAIK. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [png-mng-implement] -version-number and BeOS
Nicolas Mendoza wrote: I've seem to have run into a similar problem, what _is_ really the problem? Like I wrote in my original mail on the problem... the problem seems to be that a version type of none is not correctly handled: But, the code in ltmain.sh around line 3236 does not handle a value of none. Only for the specific list of cases does it assign a value to current, age and revision. But the check later, in line 3261, expects current to be initialized to a number, and shows an error if it's empty. (quoting http://article.gmane.org/gmane.comp.gnu.libtool.general/7325) ___ http://lists.gnu.org/mailman/listinfo/libtool
-no-undefined and GNU ld
Hi, since GNU ld supports -z defs (or the equivalent --no-undefined), I was wondering why libtool doesn't use this to enforce its -no-undefined flag? It does seem to do this on Solaris (and of course on platforms where that's the only supported behaviour). Or is the issue just that nobody made a patch for this yet? :) -christian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [png-mng-implement] -version-number and BeOS
Ralf Wildenhues wrote: Except that hack fixes a symptom, but not the underlying issue. It seems to me that this is a bug in any case. Not only is -version-number inconsistent with -version-info here. Even if BeOS has a versioning system for libraries and libtool gets support for that, this would still leave -version-number broken for other platforms where version_type=none (seems to be amigaos, os2 and sysv4 (in some cases)). Or are you saying that -version-* should not be passed to libtool if the target doesn't have versioning support? It would great if someone with BeOS access and experience investigate the versioning system they use for shared libraries, and we could code that into Libtool then, to really fix this. That would be preferrable but still leave the other mentioned platforms broken. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [png-mng-implement] -version-number and BeOS
John Bowler wrote: For BeOS try adding 'none' to the end of the test for darwin|linux|osf|windows on line 3237 of ltmain.sh. We can ship libpng with that because it won't break anything which isn't already broken. Yep, that fixes it, thanks. Will 1.2.9 contain that fix? ___ http://lists.gnu.org/mailman/listinfo/libtool
-version-number and BeOS
[sending to the libtool mailing list; cc'ing the libpng one as this makes it impossible for me to compile libpng 1.2.9rc on BeOS using configure/libtool] Hi, I think I found a bug in libtool on BeOS with -version-number. Tested libtool version is 1.5.22 (as part of libpng 1.2.9 RC) The problem is: make[1]: Entering directory `/boot/home/tmp/libpng-rc-testing/libpng-1.2.9rc1' /bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -o libpng12.la -rpath /usr/local/lib -no-undefined -export-dynamic -version-number 0:9:0 -Wl,--version-script=libpng.vers png.lo pngset.lo pngget.lo pngrutil.lo pngtrans.lo pngwutil.lo pngread.lo pngrio.lo pngwio.lo pngwrite.lo pngrtran.lo pngwtran.lo pngmem.lo pngerror.lo pngpread.lo pnggccrd.lo -lz libtool: link: CURRENT `' must be a nonnegative integer libtool: link: `0:9:0' is not valid version information make[1]: *** [libpng12.la] Error 1 (Note that libpng 1.2.8 is OK (in this regard), as it uses -version-info rather than -version-number) The cause of this problem seems to be this: For BeOS, version_type=none. But, the code in ltmain.sh around line 3236 does not handle a value of none. Only for the specific list of cases does it assign a value to current, age and revision. But the check later, in line 3261, expects current to be initialized to a number, and shows an error if it's empty. Shouldn't the case $version_type do something with "none" too? -biesi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: large messages
Ralf Wildenhues wrote: However, I guess some readers of this list might be annoyed by large messages as yours. First, please take my apology: we have moderation turned on for messages >100KB, still I just allowed it through while my mind was somewhere else. Second, Christian, it would be nice if you could pack attachments the next time (bzip2 or gzip are fine). Thank you. I have to apologize; I didn't realize that the mail was so large. I'll pack the attachment next time. -biesi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Support for creating shared C++ libraries on BeOS
Ralf Wildenhues wrote: By the way: does BeOS need the "lib" prefix for modules at all? To test a hypothetical "no" answer, I think this should work: configure $EDITOR ./libtool # set need_lib_prefix=no make check TESTS='tests/mdemo-shared.test' This passed (HEAD; I interrupted the testsuite) $EDITOR tests/mdemo/libtool # set need_lib_prefix=no make check TESTS='tests/mdemo-make.test tests/mdemo-exec.test' mdemo-exec.test failed here. Output: mdemo-exec.test: === Running mdemo-exec.test mdemo-exec.test: === Executing uninstalled programs in Welcome to GNU libtool mdemo! error during initialization: invalid loader mdemo-exec.test: ./tests/mdemo-exec.test: cannot execute tests/mdemo/mdemo_static tests/mdemo/foo1.la tests/mdemo/libfoo2.la Welcome to GNU libtool mdemo! error during initialization: invalid loader mdemo-exec.test: ./tests/mdemo-exec.test: cannot execute tests/mdemo/mdemo tests/mdemo/foo1.la tests/mdemo/libfoo2.la | mdemo-exec.test: === Running mdemo-exec.test | mdemo-exec.test: === Executing uninstalled programs in | error during initialization: invalid loader | Welcome to GNU libtool mdemo! | mdemo-exec.test: ./tests/mdemo-exec.test: cannot execute tests/mdemo/mdemo_static tests/mdemo/foo1.la tests/mdemo/libfoo2.la | error during initialization: invalid loader | Welcome to GNU libtool mdemo! | mdemo-exec.test: ./tests/mdemo-exec.test: cannot execute tests/mdemo/mdemo tests/mdemo/foo1.la tests/mdemo/libfoo2.la | FAIL: tests/mdemo-exec.test So that seems to be the same error. -biesi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Support for creating shared C++ libraries on BeOS
Ralf Wildenhues wrote: Also, we love to see testsuite output.. ;-) And here, the log of make test for HEAD. 5 tests failed... most with "invalid loader". Something wrong with libltdl? -biesi checklog-head.gz Description: PostScript document ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Support for creating shared C++ libraries on BeOS
Ralf Wildenhues wrote: Maybe you could take a look at the FIXME mentioned? Also, we love to see testsuite output.. ;-) I attached the gzipped verbose "make check" output. Seems to me like the problem is with accessing symbols in executables? -biesi checklog.gz Description: PostScript document ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Support for creating shared C++ libraries on BeOS
Hi Ralf, Ralf Wildenhues wrote: branch-2-0 is dead, 2.0 will be released from what is now CVS HEAD. I have checked in the following patches to CVS HEAD and branch-1-5, respectively. Ah, thank you for the checkins. The 2.0 branch status is somewhat unclear on the webpage, which says: HEADThe main development trunk, working towards release 2.0 branch-1-5 The 1.5 release branch. Patch releases for 1.5.x will come from here branch-2-0 The 2.0 release branch. Release for 2.0 will come from here There is a contradiction here! :) Maybe you could take a look at the FIXME mentioned? Hm, the gcc I have here (the one shipped with Zeta 1.0) does not accept --undefined... it seems to convert it to -fundefined and then complains about "unrecognized option -fundefined". ld doesn't accept it either. Also, we love to see testsuite output.. ;-) Hmm, 8 testsuite failures on the current branch-1-5 on Zeta 1.0. mdemo-exec and mdemo-inst fail 3 times each, mdemo2-exec fails once, and link-order fails. link-order has apparently some unresolved references to b_new and c in liba.a. I'll try to get a log of all the failures. -biesi ___ http://lists.gnu.org/mailman/listinfo/libtool
Support for creating shared C++ libraries on BeOS
Hi,
the attached patch fixes (implements) C++ support for shared libraries
on BeOS. It just copies the C part to the C++ section; this works fine,
I tested on Zeta.
The patch was made against libtool 1.5.16; it seems to apply to 1.5.20
as well.
Would be great if you could check it in. Looking at branch-2-0, it seems
that the same idea can be applied there, as well as on HEAD (assuming
libltdl/m4/libtool.m4 is the right file to look at).
-biesi
--- /usr/share/aclocal/libtool.m4.old 2005-10-09 02:37:34.0 +0200
+++ /usr/share/aclocal/libtool.m4 2005-10-09 02:43:35.0 +0200
@@ -2925,8 +2925,19 @@ case $host_os in
_LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o
$output_objdir/$soname $libobjs $deplibs $compiler_flags
${wl}-bE:$export_symbols ${wl}-bnoentry${allow_undefined_flag}~$AR $AR_FLAGS
$output_objdir/$libname$release.a $output_objdir/$soname'
fi
fi
;;
+ beos*)
+ if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
+ _LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported
+ # Joseph Beckenbach <[EMAIL PROTECTED]> says some releases of gcc
+ # support --undefined. This deserves some investigation. FIXME
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -nostart $libobjs $deplibs
$compiler_flags ${wl}-soname $wl$soname -o $lib'
+ else
+ _LT_AC_TAGVAR(ld_shlibs, $1)=no
+ fi
+ ;;
+
chorus*)
case $cc_basename in
*)
# FIXME: insert proper C++ library support
___
http://lists.gnu.org/mailman/listinfo/libtool
