Has any more come of this?
I've just started playing with LADSPA (The Linux Audio
Developer's Simple Plugin API http://www.ladspa.org) on my
FreeBSD 4-STABLE box, and run into a similar problem.
This is an entirely C API, and the demonstration applications
are all straight C, but some of the
In article [EMAIL PROTECTED],
Max Khon [EMAIL PROTECTED] wrote:
hi, there!
On Fri, 15 Sep 2000, John Polstra wrote:
Here is another possibility: we could call _thread_init() from
crt1.o. The patch (untested) is below. It calls _thread_init() if
and only if that symbol is defined --
hi, there!
On Fri, 15 Sep 2000, John Polstra wrote:
Here is another possibility: we could call _thread_init() from
crt1.o. The patch (untested) is below. It calls _thread_init() if
and only if that symbol is defined -- i.e., libc_r is linked in.
What do you think about this solution?
Thank you John! Linking the library with -lgcc solved the problem.
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
We are trying to create a dynamic library of extensions to PHP 4.02.
This library implements a C++ class and has a C interface using the "Extern C"
declaration.
This
hi, there!
On Fri, 15 Sep 2000, John Polstra wrote:
there were some problems with pthreads initialization (but David will not
like the way I did it -- some files in contrib/gcc should be changed).
this happened because we initialize pthreads from static object
constructor (which is not
In article [EMAIL PROTECTED],
Max Khon [EMAIL PROTECTED] wrote:
`__register_frame_info' should be called from `do_ctors' in
src/lib/csu/common/crtbegin.c to load frame information from .eh_frame
sections before any constructors are executed because try/catch can be
used in constructors of
We are trying to create a dynamic library of extensions to PHP 4.02.
This library implements a C++ class and has a C interface using the "Extern C"
declaration.
This library is linked with libstdc++.so.3 .
If the library is called in a C program = no trouble.
If the library is
In article [EMAIL PROTECTED], Nate Williams
[EMAIL PROTECTED] wrote:
At one point libgcc was shared (FreeBSD 1.*), and it caused way more
problems that it solved.
Do you remember any details? I analyzed it pretty thoroughly (I
thought) more than a year ago, and decided the shared library was
At one point libgcc was shared (FreeBSD 1.*), and it caused way more
problems that it solved.
Do you remember any details? I analyzed it pretty thoroughly (I
thought) more than a year ago, and decided the shared library was the
best solution.
If I remember right (and my memory is fuzzy
hi, there!
On Thu, 14 Sep 2000, John Polstra wrote:
Also, we _desperately_ need to switch away from the setjmp/longjmp
exception implementation and start using the now-standard DWARF2
implementation. It makes a tremendous performance difference even in
programs that don't use exceptions at
In article [EMAIL PROTECTED],
Nate Williams [EMAIL PROTECTED] wrote:
[shared libgcc?]
If I remember right (and my memory is fuzzy for stuff that far bak)
there were a couple of issues.
1) Speed. Shared libraries are slower than static libraries (PIC
et. al), and the stuff in libgcc
In article [EMAIL PROTECTED],
Max Khon [EMAIL PROTECTED] wrote:
libgcc already has support for DWARF2. the only thing that should be
changed is crtbegin.o/crtend.o.
Yes.
I have made all the necessary patches for this. I believe, David has
them.
Actually I now think we should simply build
[shared libgcc?]
If I remember right (and my memory is fuzzy for stuff that far bak)
there were a couple of issues.
1) Speed. Shared libraries are slower than static libraries (PIC
et. al), and the stuff in libgcc tends to be performance centric.
True. But if we just make it
In article [EMAIL PROTECTED],
Nate Williams [EMAIL PROTECTED] wrote:
True. But if we just make it link against "-lgcc" then knowledgeable
users can always add "-static" if they know how to deal with the
consequences and they need the performance.
Ahh, but -static implies the entire
hi, there!
On Thu, 14 Sep 2000, John Polstra wrote:
I have made all the necessary patches for this. I believe, David has
them.
Actually I now think we should simply build the crt* files from
gcc's "crtstuff.c" in the standard way, rather than having our own
versions. The gcc versions
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
We are trying to create a dynamic library of extensions to PHP 4.02.
This library implements a C++ class and has a C interface using the "Extern C"
declaration.
This library is linked with libstdc++.so.3 .
If the library is called in
16 matches
Mail list logo
