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

[Rupert Kittinger-Sereinig]

>> 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 <rks at mur.at>
Krenngasse 32
A-8010 Graz
Austria