Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1

[Andrew Reilly]

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 plugins themselves are
written in C++.  Without doing anything extra, attempting to
dlopen() one of these C++ shared libraries produced an Undefined
symbol __get_eh_context.

In the spirit John's fix (I think):

On Wed, Sep 13, 2000 at 05:49:11PM -0700, John Polstra wrote:
 As a work-around, try adding this to your main program.  (I am
 assuming it is a C++ program too.)
 
 extern void terminate(void);
 void (*kludge_city)(void) = terminate;

I didn't actually do that (took a while to find the message in
the archives), but did:
(a) Changed the source file names to .cc, so that they would be
compiled as C++ code, and
(b) added a gratuitous class definition and use to a common
file, so that __get_eh_context and friends would be included in
the executable.

Neither of these made the problem go away, which surprised me,
because nm on the resulting executable showed the symbol to be
defined.  I guess the dynamic linker doesn't look in the
executable, only the shared libraries?

This suggestion:
 Another possibility would be to link explicitly with libgcc when
 creating your dynamic library:
 
 cc -shared -o libphptest.so ... -lgcc

Works, even when the applications are compiled as ordinary C
programs again.  I haven't tried running a system with more
than one C++ plugin yet, so I worry a little that there will
be multiple definition name clashes.  If the dynamic linker is
smart enough to not worry about that, then this does seem to
be the "right" way to go, in some sense, because the resulting
shared library seems to have "pure" C linkage.

Perhaps we could put something about this in the Handbook, or
(better) the gcc info pages?

Is there a central repository of information about FreeBSD's
binutil and compiler state?  I noticed a few things in the gcc
info pages about ABI-affecting switches (thunks for vtables and
the like).  There are obviously system defaults for these
switches, but I don't know where to find out what they are.

-- 
Andrew


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1

[John Polstra]

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 -- i.e., libc_r is linked in.
  What do you think about this solution?
 
 seems ok to me but can we do this from `do_ctors' or `_init' -- they are
 located in common/

That's a good point.  But I would rather not do it from crtbegin since
there is a good chance that we'll eventually be using the GCC version
of that.  However, I have some plans to unify the versions of crt1.c
so that it can be moved into "common".  The alpha and sparc versions
are identical, and they are not very much different from the i386
version.  I think a couple of platform-specific #defines or inline
functions could handle all of the architecture dependencies.  Note,
I _don't_ want to do it using "#ifdef __i386__", etc., because that
doesn't scale well for a lot of platforms and it makes the code hard
to read.  Instead I would prefer to #include a small platform-specific
header file which defines macros and inline functions appropriately.

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra  Co., Inc.Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1

[Max Khon]

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?
 
 Index: crt1.c
 ===
 RCS file: /home/ncvs/src/lib/csu/i386-elf/crt1.c,v
 retrieving revision 1.4
 diff -u -r1.4 crt1.c
 --- crt1.c1999/08/27 23:57:57 1.4
 +++ crt1.c2000/09/16 00:30:51
 @@ -48,6 +48,9 @@
  extern int _DYNAMIC;
  #pragma weak _DYNAMIC
  
 +extern void _thread_init(void);
 +#pragma weak _thread_init
 +
  #ifdef __i386__
  #define get_rtld_cleanup()   \
  ({ fptr __value; \
 @@ -91,6 +94,8 @@
  #ifdef GCRT
  monstartup(eprol, etext);
  #endif
 +if (_thread_init != NULL)
 + _thread_init();
  _init();
  exit( main(argc, argv, env) );
  }
 

seems ok to me but can we do this from `do_ctors' or `_init' -- they are
located in common/

/fjoe



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1

[Janick.Taillandier]

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 library is linked with libstdc++.so.3 .
 
 If the library is called in a C program = no trouble.
 If the library is called from PHP with the "dlopen()" function =
 [Warning: Unable to load dynamic library
 '/users/em/ftp/php/test_cpp/debug/libphptest.so' - /usr/lib/libstdc++.so.3:
 Undefined symbol "__ti9exception" in
 /usr/local/httpd/htdocs/www/Iti_q/testso.php on line 2

This is because FreeBSD uses an archive library "libgcc.a" instead
of a shared library.  That means that everything from libgcc which
is needed by your shared libraries had better already be linked into
the main program.  The right solution is for us to use a shared
library for libgcc.  (Note to eager committers: don't do this without
coordinating with obrien.  There are ramifications that aren't
obvious.)

As a work-around, try adding this to your main program.  (I am
assuming it is a C++ program too.)

extern void terminate(void);
void (*kludge_city)(void) = terminate;

Another possibility would be to link explicitly with libgcc when
creating your dynamic library:

cc -shared -o libphptest.so ... -lgcc

That might cause other problems, but probably not.

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra  Co., Inc.Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1

[Max Khon]

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 the right thing anyway).
 
 It seemed like a good idea at the time. :-) What is the problem --
 is it that libc_r is initialized at the wrong time?  What would you
 suggest as a better method for initializing the library?  I'd hate to
 introduce a bunch of "if (!initted) { ... }" checks, since those add
 runtime overhead on every call.

`__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 static objects (`__register_frame_info'
is defined in src/contrib/gcc/frame.c, this file is linked into
libgcc[_r].a). however `__register_frame_info' uses locks and other
threading stuff (using pthreads on FreeBSD) so we must have pthreads
initialized before locks are used.

another issue with our pthreads initialization is that pthreads can be
used in static object constructors so the first `pthread_xxx' call can
happen before `_thread_init' is called from constructor of our
_thread_init_invoker (it depends on order in which constructors are placed
in .ctors section).

I see two solutions (both seem to be hacks for me):
1) we can insert if (!initted) ... in `pthread_once' (this seem to be the
first pthreads function called from __register_frame_info)
2) we can insert 

#if __GTHREADS
  _thread_init();
#endif
 
   at the very beginning of `__register_frame_info'

The second approach seems to be cleaner but require changes in
src/contrib/gcc/

/fjoe

PS I have attached patches and Makefile.inc which should be placed
into src/lib/csu. Makefile.inc can be slightly out of date (I made it
somewhere around May/Jun 2000)


--- contrib/gcc/config/freebsd.h.orig   Wed Jul 19 07:30:53 2000
+++ contrib/gcc/config/freebsd.hSun Jul 23 17:59:33 2000
@@ -137,12 +137,6 @@
 #undef  HANDLE_SYSV_PRAGMA
 #define HANDLE_SYSV_PRAGMA
 
-/* FreeBSD ELF using our home-grown crtbegin.o/crtend.o does not support the
-   DWARF2 unwinding mechanisms.  Once `make world' bootstraping problems with
-   the EGCS crtstuff.c is overcome, we will switch to the non-sjlj-exceptions 
-   type exception machanism.  */
-#define DWARF2_UNWIND_INFO 0
-
 /* Do not use ``thunks'' to implement C++ vtables.  This method still has
fatal bugs.  Also, GCC 3.0 will have a new C++ ABI that may not even
support `thunks'.  */
--- contrib/gcc/frame.c.origMon Jul 24 00:29:25 2000
+++ contrib/gcc/frame.c Mon Jul 24 00:33:28 2000
@@ -725,6 +725,10 @@
 void
 __register_frame_info (void *begin, struct object *ob)
 {
+#if __GTHREADS
+  _thread_init();
+#endif
+
   ob-fde_begin = begin;
 
   ob-pc_begin = ob-pc_end = 0;
--- lib/csu/common/crtbegin.c.orig  Mon Jul 10 16:15:25 2000
+++ lib/csu/common/crtbegin.c   Mon Jul 24 00:36:25 2000
@@ -26,6 +26,9 @@
  */
 
 #include sys/param.h
+#include "tm.h"
+#include "defaults.h"
+#include frame.h
 
 #define ABI_VENDOR "FreeBSD"
 #define ABI_SECTION".note.ABI-tag"
@@ -33,13 +36,23 @@
 
 typedef void (*fptr)(void);
 
+extern void __register_frame_info(void *, struct object *)
+   __attribute__((weak));
+extern void *__deregister_frame_info(void *)
+   __attribute__((weak));
+
 static fptr ctor_list[1] __attribute__((section(".ctors"))) = { (fptr) -1 };
 static fptr dtor_list[1] __attribute__((section(".dtors"))) = { (fptr) -1 };
+static char eh_frame_begin[] __attribute__((section(".eh_frame"))) = { };
 
 static void
 do_ctors(void)
 {
 fptr *fpp;
+static struct object object;
+
+if (__register_frame_info)
+   __register_frame_info(eh_frame_begin, object);
 
 for(fpp = ctor_list + 1;  *fpp != 0;  ++fpp)
;
@@ -54,6 +67,9 @@
 
 for(fpp = dtor_list + 1;  *fpp != 0;  ++fpp)
(**fpp)();
+
+if (__deregister_frame_info)
+   __deregister_frame_info(eh_frame_begin);
 }
 
 /*
--- lib/csu/common/crtend.c.origMon Jul 10 16:15:28 2000
+++ lib/csu/common/crtend.c Sun Jul 23 17:59:33 2000
@@ -26,8 +26,11 @@
  */
 
 #include sys/cdefs.h
+#include sys/types.h
 
 typedef void (*fptr)(void);
 
 static fptr ctor_end[1] __attribute__((section(".ctors"))) __unused = { 0 };
 static fptr dtor_end[1] __attribute__((section(".dtors"))) __unused = { 0 };
+static u_int32_t eh_frame_end[1] __attribute__((section(".eh_frame")))
+__unused = { 0 };


TARGET_ARCH?=   ${MACHINE_ARCH}

.if ${TARGET_ARCH} == "mipsel" || ${TARGET_ARCH} == "mipseb"
GCC_ARCH=   mips
.else 
GCC_ARCH=   ${TARGET_ARCH}
.endif
GCCDIR= ${.CURDIR}/../../../contrib/gcc

Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1

[John Polstra]

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 static objects (`__register_frame_info'
 is defined in src/contrib/gcc/frame.c, this file is linked into
 libgcc[_r].a). however `__register_frame_info' uses locks and other
 threading stuff (using pthreads on FreeBSD) so we must have pthreads
 initialized before locks are used.
 
 another issue with our pthreads initialization is that pthreads can be
 used in static object constructors so the first `pthread_xxx' call can
 happen before `_thread_init' is called from constructor of our
 _thread_init_invoker (it depends on order in which constructors are placed
 in .ctors section).
 
 I see two solutions (both seem to be hacks for me):
 1) we can insert if (!initted) ... in `pthread_once' (this seem to be the
 first pthreads function called from __register_frame_info)
 2) we can insert 
 
 #if __GTHREADS
   _thread_init();
 #endif
  
at the very beginning of `__register_frame_info'
 
 The second approach seems to be cleaner but require changes in
 src/contrib/gcc/

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?

John

Index: crt1.c
===
RCS file: /home/ncvs/src/lib/csu/i386-elf/crt1.c,v
retrieving revision 1.4
diff -u -r1.4 crt1.c
--- crt1.c  1999/08/27 23:57:57 1.4
+++ crt1.c  2000/09/16 00:30:51
@@ -48,6 +48,9 @@
 extern int _DYNAMIC;
 #pragma weak _DYNAMIC
 
+extern void _thread_init(void);
+#pragma weak _thread_init
+
 #ifdef __i386__
 #define get_rtld_cleanup() \
 ({ fptr __value;   \
@@ -91,6 +94,8 @@
 #ifdef GCRT
 monstartup(eprol, etext);
 #endif
+if (_thread_init != NULL)
+   _thread_init();
 _init();
 exit( main(argc, argv, env) );
 }


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1

[Nate Williams]

  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 called from PHP with the "dlopen()" function =
  [Warning: Unable to load dynamic library
  '/users/em/ftp/php/test_cpp/debug/libphptest.so' - /usr/lib/libstdc++.so.3:
  Undefined symbol "__ti9exception" in
  /usr/local/httpd/htdocs/www/Iti_q/testso.php on line 2
 
 This is because FreeBSD uses an archive library "libgcc.a" instead
 of a shared library.  That means that everything from libgcc which
 is needed by your shared libraries had better already be linked into
 the main program.  The right solution is for us to use a shared
 library for libgcc.

At one point libgcc was shared (FreeBSD 1.*), and it caused way more
problems that it solved.




Nate


  (Note to eager committers: don't do this without
 coordinating with obrien.  There are ramifications that aren't
 obvious.)
 
 As a work-around, try adding this to your main program.  (I am
 assuming it is a C++ program too.)
 
 extern void terminate(void);
 void (*kludge_city)(void) = terminate;
 
 Another possibility would be to link explicitly with libgcc when
 creating your dynamic library:
 
 cc -shared -o libphptest.so ... -lgcc
 
 That might cause other problems, but probably not.
 
 John
 -- 
   John Polstra   [EMAIL PROTECTED]
   John D. Polstra  Co., Inc.Seattle, Washington USA
   "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa
 
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-hackers" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1

[John Polstra]

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 the
best solution.  At that time I asked PHK what the reasons were for
eliminating the shared libgcc.  (He is the person who got rid of it.
See "src/gnu/lib/libgcc/Makefile" revisions 1.5 - 1.8.)  He said he
didn't think it would be a problem to make it shared again.

At that time, I converted my -current system to using a shared libgcc
and ran it like that for 6 months at least without any problems.  I
believe David O'Brien was also using a shared libgcc for a long time
without problems.

The non-shared libgcc used to work for us mainly because on the i386
architecture practically nothing from libgcc was ever used.  That
is no longer the case, because of all the exception support that
has been added to it for C++.  If a shared library uses exceptions
(as does libstdc++) but the main program doesn't, you get undefined
symbol errors as the original poster reported.  Using a shared libgcc
completely solves that.

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 all.  (I measured it once.)  But
that in turn requires more support from libgcc, and exacerbates the
problems associated with using a non-shared libgcc.

The egcs team used to argue vociferously against making libgcc shared.
However, I found their list of reasons and decided that they didn't
apply to us.  In my view, many of the reasons boiled down to, "It
would be too inconvenient for Red Hat."  I.e., they didn't want to
use their shared library version numbers the way they are supposed to
be used.  Also, many of the arguments against a shared libgcc which
might make sense when gcc is a 3rd-party add-on just don't apply when
it is _the_ system compiler.  I don't follow the gcc mailing lists any
more, but David O'Brien told me some months ago that they had done a
complete turn-around on the issue and were planning on making libgcc
shared again.  (David, please correct me if I'm misrepresenting what
you told me.)

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra  Co., Inc.Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1

[Nate Williams]

  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 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.
2) Ease of use.  Everytime we upgrade or modify libgcc, it required
   keeping around the old libgcc.so.  I don't think we had much
   experience with versioning back then, so we tended to either 'never'
   increment the versions or 'overdo' it.

We weren't making releases nearly as often then, so keeping backwards
compatability was more difficult as people tended to be running -stable
instead of releases.  Nowadays we handle backwards compatability better,
so having N different versions of libgcc is still annoying, but easier
to deal with (/usr/lib/compat).

 At that time, I converted my -current system to using a shared libgcc
 and ran it like that for 6 months at least without any problems.  I
 believe David O'Brien was also using a shared libgcc for a long time
 without problems.

There were no problems, it was just annoying.  Many were of the opinion
that 'not everything should be linked shared', since it tends to clutter
up /usr/lib, and also tends to slow things down.

Static linking isn't always bad

 The non-shared libgcc used to work for us mainly because on the i386
 architecture practically nothing from libgcc was ever used.

Aren't there quite a few 'math' routines inside libgcc (mods and diffs
and all sorts of low-level 32/64 bit routines that are quite often used..)

 That is no longer the case, because of all the exception support that
 has been added to it for C++.  If a shared library uses exceptions (as
 does libstdc++) but the main program doesn't, you get undefined symbol
 errors as the original poster reported.  Using a shared libgcc
 completely solves that.

Ahh.  Can't we just make the linker *always* add libgcc onto the end?
Because it's a static library, if it's the symbol isn't used, then it
won't be linked into the library?

 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 all.  (I measured it once.)  But
 that in turn requires more support from libgcc, and exacerbates the
 problems associated with using a non-shared libgcc.

How so?


Nate


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1

[Max Khon]

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 all.  (I measured it once.)  But
 that in turn requires more support from libgcc, and exacerbates the
 problems associated with using a non-shared libgcc.

libgcc already has support for DWARF2. the only thing that should be
changed is crtbegin.o/crtend.o.
I have made all the necessary patches for this. I believe, David has them.

/fjoe



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1

[John Polstra]

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 tends to be performance centric.

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.

 2) Ease of use.  Everytime we upgrade or modify libgcc, it required
keeping around the old libgcc.so.  I don't think we had much
experience with versioning back then, so we tended to either 'never'
increment the versions or 'overdo' it.

Luckily, libgcc doesn't seem to be changing very often/much these
days.

 Aren't there quite a few 'math' routines inside libgcc (mods and diffs
 and all sorts of low-level 32/64 bit routines that are quite often used..)

I think most of the stuff that's actually used for C is just for the
relatively rare 64-bit operations on the i386.

 Ahh.  Can't we just make the linker *always* add libgcc onto the end?
 Because it's a static library, if it's the symbol isn't used, then it
 won't be linked into the library?

I assume you mean always add it onto the end when building shared
libraries.  That's problematic because the exception stuff uses some
static variables inside libgcc, and you end up with multiple copies of
them.

  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 all.  (I measured it once.)  But
  that in turn requires more support from libgcc, and exacerbates the
  problems associated with using a non-shared libgcc.
 
 How so?

Well, I should have made that a separate topic as it doesn't have that
much to do with whether libgcc is shared or not.  But what I meant
was that the DWARF2 exception support uses more stuff from libgcc, so
you're more likely to run into an undefined symbol if libgcc is not
shared.  Probably a bogus point for this discussion.

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra  Co., Inc.Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1

[John Polstra]

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 the crt* files from
gcc's "crtstuff.c" in the standard way, rather than having our own
versions.  The gcc versions are messy but they work fine, and they are
specifically exempted from the GPL as long as they are used together
with gcc.

There are some potential problems with backward compatibility when
making this change, but we need to do it anyway.  The performance
penalty from the sjlj exceptions is really terrible.  I think I
decided that using a shared libgcc would help with the compatibility
issues when I looked at the problem a long time ago.  But I can't
remember the details any more.

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra  Co., Inc.Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1

[Nate Williams]

 [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 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 enchilada is linked static, which
may not be the case. :(

  2) Ease of use.  Everytime we upgrade or modify libgcc, it required
 keeping around the old libgcc.so.  I don't think we had much
 experience with versioning back then, so we tended to either 'never'
 increment the versions or 'overdo' it.
 
 Luckily, libgcc doesn't seem to be changing very often/much these
 days.
 
  Aren't there quite a few 'math' routines inside libgcc (mods and diffs
  and all sorts of low-level 32/64 bit routines that are quite often used..)
 
 I think most of the stuff that's actually used for C is just for the
 relatively rare 64-bit operations on the i386.

Bruce would know more.  I know that the JDK uses them, but then again it
also does 64-bit math, so that may be the case. :)

  Ahh.  Can't we just make the linker *always* add libgcc onto the end?
  Because it's a static library, if it's the symbol isn't used, then it
  won't be linked into the library?
 
 I assume you mean always add it onto the end when building shared
 libraries.  That's problematic because the exception stuff uses some
 static variables inside libgcc, and you end up with multiple copies of
 them.

Hmmm

   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 all.  (I measured it once.)  But
   that in turn requires more support from libgcc, and exacerbates the
   problems associated with using a non-shared libgcc.
  
  How so?
 
 Well, I should have made that a separate topic as it doesn't have that
 much to do with whether libgcc is shared or not.  But what I meant
 was that the DWARF2 exception support uses more stuff from libgcc, so
 you're more likely to run into an undefined symbol if libgcc is not
 shared.  Probably a bogus point for this discussion.

Gotcha...


Nate


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1

[John Polstra]

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 enchilada is linked static, which
 may not be the case. :(

Then you can sprinkle in the appropriate "-Wl,-Bstatic" and
"-Wl,-Bdynamic" options in the right places.

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra  Co., Inc.Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1

[Max Khon]

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 are messy but they work fine, and they are
 specifically exempted from the GPL as long as they are used together
 with gcc.

changes to crt* files to support DWARF2 are minimal, however.
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 the right thing anyway).
there are some workarounds (to not change anything improted from vendor
branch), of course.

/fjoe



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1

[John Polstra]

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 a C program = no trouble.
 If the library is called from PHP with the "dlopen()" function =
 [Warning: Unable to load dynamic library
 '/users/em/ftp/php/test_cpp/debug/libphptest.so' - /usr/lib/libstdc++.so.3:
 Undefined symbol "__ti9exception" in
 /usr/local/httpd/htdocs/www/Iti_q/testso.php on line 2

This is because FreeBSD uses an archive library "libgcc.a" instead
of a shared library.  That means that everything from libgcc which
is needed by your shared libraries had better already be linked into
the main program.  The right solution is for us to use a shared
library for libgcc.  (Note to eager committers: don't do this without
coordinating with obrien.  There are ramifications that aren't
obvious.)

As a work-around, try adding this to your main program.  (I am
assuming it is a C++ program too.)

extern void terminate(void);
void (*kludge_city)(void) = terminate;

Another possibility would be to link explicitly with libgcc when
creating your dynamic library:

cc -shared -o libphptest.so ... -lgcc

That might cause other problems, but probably not.

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra  Co., Inc.Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message