On Apr 1, 2008, at 10:56 AM, Eliyahu Skoczylas wrote:

> Well, here's the relevant output from the library, which shows that  
> the
> library does indeed use "name-mangled" IOS functions from C++.  I  
> don't
> know WHY, but it is undeniable that the references require C++.
> | % nm -u /usr/local/lib/libbeecrypt.so
> |
> | Undefined symbols from /usr/local/lib/libbeecrypt.so:
> |    .div
> |    .rem
> |    .udiv
> |    .umul
> |    .urem
> |    _Jv_RegisterClasses
> |    _Unwind_Resume
> |    _ZNKSt9basic_iosIcSt11char_traitsIcEE5widenEc
> |    _ZNSolsEm
> |    _ZNSt8ios_base4InitC1Ev
> |    _ZNSt8ios_base4InitD1Ev
> |    ___errno
> ... and so on.
>

Then you've mis-built beecrypt. I have no mangled symbols in  
libbeecrypt.

> I tried the advice from this thread
> <http://gcc.gnu.org/ml/gcc-bugs/2004-05/msg00123.html> and I tried  
> just
> changing my /usr/include/assert.h, which was indeed way out of  
> date, but
> that by itself wouldn't fix configure.  Apparently I need to  
> rebuild Gcc
> (which, incidentally, I got from SunFreeSource as a binary,) with the
> updated assert.h.
>

What problem are you trying to solve? Building beecrypt without C++
will get rpm built. Supplying __eprintf to the linker when building rpm
is an entirely different problem.

> What really bothers me, though, is that when I installed BeeCrypt,  
> I ran
>     make check
> and I passed all the texts there without batting an eyelash.  Why  
> didn't
> this library problem get picked up then, by any of the 15 tests in the
> suite?  When it says
>     ===================
>     All 15 tests passed
>     ===================
> I tend to take it at its word and assume that the installation is
> correct.
>

Sure beecrypt "make check" likely succeeds. That does not mean that
the installed libraries can be used without addition linker directives.

73 de Jeff