[EMAIL PROTECTED] wrote:
Marc Wilhelm Kuester wrote:
Your analysis seems to me highly plausible, especially since the
application compiles and links OK under Linux with a newer gcc 4 (4.0.2
as opposed to Apple's 4.0.0 20041026). However, adding the public
member functions etc. did not cure the situation and I'm still groping
in the dark :-(
According to a post here:
http://blog.gmane.org/gmane.os.apple.fink.general/month=20050701
...these errors may also happen when linking libraries or objects compiled
with g++ 4.0 to ones compiled with g++ 3.3. There has been a standard on
name mangling since g++ 3.0, I believe, but the details of that
specification and its implementation do still vary a bit from release to
release. So make sure you're using the exact same compiler version for
libpqxx and your own application.
I downloaded the 2.6.0 version, but ran into a compile-time error:
-------
util.cxx: In function `const char* pqxx::internal::strerror_wrapper(int,
char*, size_t)':
util.cxx:727: error: invalid conversion from 'int' to 'const char*'
make[1]: *** [util.lo] Error 1
-------
Aieee! This one has to do with a really, really nasty problem. There are
at least three different kinds of strerror_r() about:
* the AIX version, which is no big problem and so I'll ignore it here;
* the Single Unix Specification or SUS one, which returns int;
* the GNU version, which returns char *.
Detecting the difference between the latter two at build time is really
hard because they take the exact same arguments! This wouldn't be a
problem if we could afford to ignore the returned value, but with the GNU
version, we can't. We need special-case code for these, selected at build
time.
In your case, the configure script guessed (incorrectly!) that you have
the GNU version--or at least that you don't have the SUS version. The
guessing logic is supposed to check for situations where both checks fail,
perhaps for entirely unrelated reasons such as compiler warnings, but
perhaps this is a case that snuck through.
Could you post the include/pqxx/config-compiler-internal.h and config.log
(just the part that mentions strerror_r will do--the whole file would be a
bit large) as generated for your system by the configure script?
Jeroen
_______________________________________________
Libpqxx-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
It's not of my concern, but you could on top of these functions
strerror_r() create another API that wraps the strerror_r().
This could deal with the differences
_______________________________________________
Libpqxx-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
