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
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
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
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
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
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
[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
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?
___
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
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
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
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
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
13 matches
Mail list logo