Support for creating shared C++ libraries on BeOS

2005-10-08 Thread Christian Biesinger
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. Looki

Re: Support for creating shared C++ libraries on BeOS

2005-10-09 Thread Christian Biesinger
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: HEAD

Re: Support for creating shared C++ libraries on BeOS

2005-10-09 Thread Christian Biesinger
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 docu

Re: Support for creating shared C++ libraries on BeOS

2005-10-09 Thread Christian Biesinger
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 ___ h

Re: Support for creating shared C++ libraries on BeOS

2005-10-30 Thread Christian Biesinger
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 testsu

Re: large messages

2005-10-30 Thread Christian Biesinger
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 i

-version-number and BeOS

2006-03-31 Thread Christian Biesinger
[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 prob

Re: [png-mng-implement] -version-number and BeOS

2006-03-31 Thread Christian Biesinger
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? ___

Re: [png-mng-implement] -version-number and BeOS

2006-04-01 Thread Christian Biesinger
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 w

-no-undefined and GNU ld

2006-04-11 Thread Christian Biesinger
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 ma

Re: [png-mng-implement] -version-number and BeOS

2006-05-13 Thread Christian Biesinger
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 v

Re: libtool / SkyOS / ELF

2006-05-13 Thread Christian Biesinger
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 stil

Re: Making shared libraries (DLLs) on Windows: -no-undefined

2007-04-30 Thread Christian Biesinger
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