Re: [HACKERS] PG Extensions: Must be statically linked?

2006-03-03 Thread Andreas Seltenreich
Mark Dilger writes: > I have had the same concern, though never any hard evidence of a > problem. If the C++ functions are wrapped with "extern C", and all > exceptions caught (perhaps converted into error numbers which are then > returned from the wrapper functions to the plain-C calling functio

Re: [HACKERS] PG Extensions: Must be statically linked?

2006-03-03 Thread Mark Dilger
Tom Lane wrote: My concern about how nicely libstdc++ will play in the backend environment still stands though. I have had the same concern, though never any hard evidence of a problem. If the C++ functions are wrapped with "extern C", and all exceptions caught (perhaps converted into error

Re: [HACKERS] PG Extensions: Must be statically linked?

2006-03-03 Thread Tom Lane
"Craig A. James" <[EMAIL PROTECTED]> writes: > So now my question is: Can I somehow add other directories/libraries > to those that Postgres uses? This is not a Postgres problem, it's a dynamic-linker problem, and I don't believe there is a different dynamic linker for C++ than C. Your problem is

Re: [HACKERS] PG Extensions: Must be statically linked?

2006-03-03 Thread Martijn van Oosterhout
On Fri, Mar 03, 2006 at 07:46:06AM -0800, Craig A. James wrote: > Thanks for your answers -- see below. > > Based on Peter's and Tom's replies regarding C++, I think you've answered > my question: I should be able to do this without static linking. But the > Postgres linker uses the C (not the

Re: [HACKERS] PG Extensions: Must be statically linked?

2006-03-03 Thread Craig A. James
Peter Eisentraut wrote: Unfortunately, we're also using a second library (OpenBabel) that is written in C++. A good portion of the code I've written is a wrapper layer that hides the C++ objects and presents a simple C wrapper that works for Postgres. I suggest if you want to get any concrete

Re: [HACKERS] PG Extensions: Must be statically linked?

2006-03-02 Thread John Gray
On Thu, 02 Mar 2006 13:43:35 -0800, Craig A. James wrote: > I'm creating user-defined server extensions, written in C per the manual [snip] > Is this correct? Do Postgres extension need to be fully statically > linked? Or is there some configuration that will specify LD_LIBRARY_PATH > (or perha

Re: [HACKERS] PG Extensions: Must be statically linked?

2006-03-02 Thread Peter Eisentraut
Craig A. James wrote: > Unfortunately, we're also using a second library (OpenBabel) that is > written in C++. A good portion of the code I've written is a wrapper > layer that hides the C++ objects and presents a simple C wrapper that > works for Postgres. I suggest if you want to get any concre

Re: [HACKERS] PG Extensions: Must be statically linked?

2006-03-02 Thread Craig A. James
Tom Lane wrote: I'm creating user-defined server extensions, written in C per the manual "31.9. C-Language Functions". Everything works well, but only if I fully link the .so such that there are *no* unresolved external references at all. Not even the stuff in libstdc++.a can be left out. If

Re: [HACKERS] PG Extensions: Must be statically linked?

2006-03-02 Thread Tom Lane
"Craig A. James" <[EMAIL PROTECTED]> writes: > I'm creating user-defined server extensions, written in C per the > manual "31.9. C-Language Functions". Everything works well, but only > if I fully link the .so such that there are *no* unresolved external > references at all. Not even the stuff in

Re: [HACKERS] PG Extensions: Must be statically linked?

2006-03-02 Thread Peter Eisentraut
Craig A. James wrote: > I'm creating user-defined server extensions, written in C per the > manual "31.9. C-Language Functions". Everything works well, but only > if I fully link the .so such that there are *no* unresolved external > references at all. What happens if you don't? -- Peter Eisent

[HACKERS] PG Extensions: Must be statically linked?

2006-03-02 Thread Craig A. James
I'm creating user-defined server extensions, written in C per the manual "31.9. C-Language Functions". Everything works well, but only if I fully link the .so such that there are *no* unresolved external references at all. Not even the stuff in libstdc++.a can be left out. I've tried setting