[lsb-discuss] LSB Porting errors

[Wichmann, Mats D]

>I see. Do you suggest setting up an LSB build environment with 
>an gcc 3.x.x compiler instead of using gcc 4?

No, I'm not currently aware of any specific reason why you
can't use gcc4.  There was one minor issue which has been
worked around inside lsbcc.

>> one question: is your build specifying a separate command
>> for producing a shared object?  I've seen some setups
>> where there's a separate command specified as "ld -shared",
>> if so, please make sure that command is "lsbcc", not "ld".
>Indeed! Thanks for this one. I forgot to do an export LD=lsbcc before 
>running ./configure. This fixed the first linking errors. 

Okay, this is good news.

>I get other errors now. Maybe you can help me again with this problem.
>Please see the attached error log output from make.
>
>Especially errors like the one below are irritating me:
><snip>
>/usr/lib/libfontconfig.so: undefined reference to 
>`__vfprintf_chk at GLIBC_2.3.4'
>/usr/lib/libfontconfig.so: undefined reference to 
>`__fprintf_chk at GLIBC_2.3.4'

Yes, this issue is unfortunately VERY familiar, and
it's that libtool is being more helpful than we'd like.

>Shouldn't lsbc++ take the libraries from /opt/lsb/lib instead 
>of /usr/lib/? 

Yes.  Let me explain what is happening here.
lsbcc (it's the same program as lsbc++) has a list of 
the shared libraries provided by the LSB.  You can 
extend the list of valid shared libraries with LSBCC_SHAREDLIBS
as you know as you're already doing this. As lsbc++ examines
the command line preparatory to passing it on to g++, it
looks at each "-lfoo".  If foo is in the list of shared
libraries, it's left alone; if not the rewritten command
line wraps it so it looks like "-Wl,-Bstatic -lfoo -Wl,-Bdynamic".

It's assumed that if you give a full path to a file
you know what you're doing and lsbcc doesn't try to do
any recognition on it.

However, tools like libtool and pkgconfig may cause full
paths to libraries to be extracted from configuration files
external to your build process (.la or .pc files) and
added to the command line *before* lsbc++ is called.

You can see the effect of this in the command line in your
logfile:

/bin/sh ../libtool --tag=CXX --mode=link lsbc++  -Wall -O0
-funsigned-char   -o tfprint -lxml2 -lxslt -ltbarcode2 -lfontconfig
-lfreetype -lpthread -ldl  tfprint-StdAfx.o tfprint-TFPrint.o
tfprint-tfpcmdlineinfo.o -L../TFORMer_AX_Dll -lTFORMerDLL
-L../TECLicenseLib/ -lteclicense_static -L../TFSPrintDataLib/
-ltfsprintdata_static  
lsbc++ -Wall -O0 -funsigned-char -o tfprint tfprint-StdAfx.o
tfprint-TFPrint.o tfprint-tfpcmdlineinfo.o
-L/home/dominiks/tecit/TFORMer/TFORMer_AX_Dll
/home/dominiks/tecit/TFORMer/TFORMer_AX_Dll/.libs/libTFORMerDLL.a
/usr/lib/libfontconfig.so /usr/lib/libexpat.so /usr/lib/libfreetype.so
-lpthread -L/home/dominiks/tecit/TFORMer/TECXmlLib -L/usr/lib

You can see that libtool has helpfully added:

/usr/lib/libfontconfig.so /usr/lib/libexpat.so /usr/lib/libfreetype.so

and so these neither come from /opt/lsb/lib (fontconfig is
in the LSB as of 3.1) nor are turned into static links.
You can also see that -lTFORMerDLL got stuffed in as a .a,
hope that's what was intended.  This has all happened before
lsbc++ has had a chance at the command line yet.

We've worked around this in various semi-unappealing ways,
such as supplying customized libtool files for /opt/lsb/lib
and making sure that this is in the path for libtool - I
forget what that looks like for libtool, for pkgconfig-using
stuff, it's setting PKG_CONFIG_PATH. 

Sorry you're tripping into the harder parts using lsbcc.
We haven't had "real" users in this area, only our internal
porting efforts. Hopefully if you can bear with us we can
find ways to improve this stuff.