gnutls-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnutls-dev] Building GnuTLS 1.6.1 under Mac OS X (fwd)


From: Rupert Kittinger-Sereinig
Subject: Re: [gnutls-dev] Building GnuTLS 1.6.1 under Mac OS X (fwd)
Date: Thu, 01 Feb 2007 18:55:51 +0100
User-agent: Thunderbird 1.5.0.5 (X11/20060719)


I looked up the mail that reported the error, and it seems that the compiler fails to create an instance of the set_ptr() member function in the object file. In this case, I would try to uninline set_ptr(). This can hardly be a performance problem and should fix the linker error :-)

I'd really appreciate your help here.  What would your recommendation
be, more specifically?  The old code is the one which is used when the
newly added #if's are not chosen.  I've seen other bug reports too,
such as this failure:

verify-elf: ERROR: ./usr/lib/libgnutlsxx.so.13.2.2: undefined symbol: _ZN6gnutls11credentials7set_ptrEPv

But that may actually be the same, I don't know...

/Simon

Hi Simon,

to make sense of the above error message, you need to feed it through c++filt, so we get

/usr/lib/libgnutlsxx.so.13.2.2: undefined symbol: gnutls::credentials::set_ptr(void*)

So, gnutls::credentials::set_ptr(void*) is missing from the library.

The reason is almost certainly that the functions was declared inline. (Note that all functions defined in a class declaration are implicitely inline...). Now if some client code calls this function, but the compiler fails to inline the function, the linker will complain.

I have seen this happen with some older version of g++ (but I do not remember which...) if optimization is not turned on. To have everything inlined, at least -O0 had to be present. Also, there is a g++ option -fkeep-inline-functions that should probably be enabled whenever compiling a library.

I have no access to a Mac, so I cannot check my conclusions, but if they are correct, I see two ways to fix this:

1) use compiler options. Will probably lead to a maintainance nightmare sooner or later.

2) do not use inline functions in the library API. This is what C++ gurus recommend anyway ("never use inline functions unless profiling shows that it is actually useful"). In the case of gnutls, the cost of a few functions calls is probably irrelevant compared with the cost of the cryptographic algoritms, so this probably the better solution.

I will try to provide a patch, but this will take some time. Also, some Mac users will need to test it for me.

Rupert

--
Rupert Kittinger-Sereinig <address@hidden>
Krenngasse 32
A-8010 Graz
Austria




reply via email to

[Prev in Thread] Current Thread [Next in Thread]