Re: [courier-users] Disabling TLS 1.0?

[Sam V. <mr...@co...>]

Greg Earle writes:

> I have courier-unicode 2.0 successfully built & installed but when I went to  
> build courier-authlib 0.68.0 it splatted pretty early on:
>
> --
> [...]
> libtool: link: ( cd ".libs" && rm -f "librfc822.la" && ln -s  
> "../librfc822.la" "librfc822.la" )
> source='testsuite.c' object='testsuite.o' libtool=no \
> DEPDIR=.deps depmode=none /bin/bash ./../../depcomp \
> cc -DHAVE_CONFIG_H -I.      -I/usr/gnu/include -I/opt/courier/include -I.. - 
> I./.. -c -o testsuite.o testsuite.c
> /bin/bash ./libtool  --tag=CC    --mode=link cc  -I/usr/gnu/include - 
> I/opt/courier/include -I.. -I./..  -static -L/opt/courier/lib - 
> R/opt/courier/lib -L/usr/gnu/lib -R/usr/gnu/lib -o testsuite testsuite.o  
> librfc822.la -lcourier-unicode
> libtool: link: cc -I/usr/gnu/include -I/opt/courier/include -I.. -I./.. -o  
> testsuite testsuite.o  -L/opt/courier/lib -L/usr/gnu/lib ./.libs/librfc822.a  
> /opt/courier/lib/libcourier-unicode.so -R/opt/courier/lib -R/opt/courier/lib  
> -R/usr/gnu/lib
> Undefined                       first referenced
>  symbol                             in file
> _Znwj                               /opt/courier/lib/libcourier-unicode.so
> _ZNSs4_Rep11_S_terminalE            /opt/courier/lib/libcourier-unicode.so
>
> I discovered that if instead of "cc" I use "CC -std=c++11" as the linker, it  
> links.
>
> It feels like the as-configured compilation environment didn't pick up the  
> COURIER_UNICODE_CXXFLAGS="-std=c++11" setting from aclocal.m4 somehow ...

libcourier-unicode.so contains a mixture of C and C++ code and is linked  
with the C++ library.

testsuite is C only code that links with libcourier-unicode.so.

> Anyway if I add "-std=c++11" to $CXXFLAGS I get a bit further, but then it  
> hits

It looks like Solaris, at least for you, does not record dependencies  
in .sos, so you need to i use CC as a link so that testsuite gets linked  
against the C++ library itself, in order to satisfy libcourier-unicode.so's  
dependencies.

> --
> source='testgdbm.C' object='testgdbm.o' libtool=no \
> DEPDIR=.deps depmode=none /bin/bash ./../../depcomp \
> CC -DHAVE_CONFIG_H -I.      -std=c++11 -I/opt/courier/include - 
> I/usr/gnu/include -c -o testgdbm.o testgdbm.C
> /bin/bash ./libtool  --tag=CXX    --mode=link CC   -std=c++11 - 
> I/opt/courier/include -I/usr/gnu/include -static -L/opt/courier/lib - 
> R/opt/courier/lib -L/usr/gnu/lib -R/usr/gnu/lib -o testgdbm testgdbm.o  
> libgdbmobj.la
> libtool: link: CC -std=c++11 -I/opt/courier/include -I/usr/gnu/include -o  
> testgdbm testgdbm.o  -L/opt/courier/lib -L/usr/gnu/lib ./.libs/libgdbmobj.a  
> /usr/gnu/lib/libgdbm.so -R/usr/gnu/lib -R/usr/gnu/lib -R/opt/courier/lib
> unused $ADDVERS specification from file  
> '/opt/developerstudio12.5/lib/compilers/CC-gcc/gcc_version.map' for object  
> 'libgcc_s.so'
> version(s):
>         GCC_4.2.0
> *** Error code 2
> make: Fatal error: Command failed for target `testgdbm'
> Current working directory /pkg/src/mail/Courier/courier- 
> authlib-0.68.0/libs/gdbmobj
> *** Error code 1
> make: Fatal error: Command failed for target `all'
> Current working directory /pkg/src/mail/Courier/courier- 
> authlib-0.68.0/libs/gdbmobj
> --
>
> I think my homegrown "libgdbm.so" might've been built with an old GCC; maybe  
> that's why I'm getting this complaint?

Yes. C++ code is, generally, not ABI compatible with different versions even  
of the same compiler.

If you have C++ anywhere, it must be built by the same compiler, and same  
version. gcc itself has actually a pretty good track record of backwards  
compatibility, and current versions of gcc will generally link with  
libraries built by older versions, but gcc 4.2 is just too old.

And even if older gcc code links, I wouldn't trust the results.