[lsb-discuss] undefined reference to `__isoc99_sscanf

Craig Scott craig.scott at csiro.au
Wed Dec 29 14:03:16 PST 2010

On Thu, 30 Dec 2010 12:45:32 am Wichmann, Mats D wrote:
> lsb-discuss-bounces at lists.linux-foundation.org wrote:
> > Hi all. Sorry for the bombardment of LSB+Qt posts today. ;)
> > After applying various workarounds, I have managed to get most
> > of Qt building against LSB 4.0 on a SLED11.1 machine. However,
> > I'm pretty much stumped on one point and I suspect others on
> > this list will be able to provide some hints on where to look.
> > All the Qt libraries I need can now be built, but I encounter
> > an issue when an executable tries to link against them (for
> > the curious, it is linking the assistant executable and the
> > problem library reported is QtNetwork). The tail of the error message
> > is: 
> > 
> > /path/hidden/Build/qt-everywhere-opensource-src-4.7.1/lib/libQt
> Network.so: undefined reference to `__isoc99_sscanf'
> > collect2: ld returned 1 exit status
> > 
> > The funny thing is, even when none of the source code that
> > goes into libQtNetwork.so uses sscanf, I still see this error.
> > There is only one usage of sscanf in that library's source and
> > I removed it but still got the above. I've seen various Google
> > posts that suggest defining __GNU_SOURCE as a workaround, but
> > this doesn't seem to be tackling the right problem for me. It
> > is almost as though some other library is creeping into the link, but
> > I can't see how. 
> > 
> > I know it's pretty hard without all the details of my build,
> > but if anyone has any suggestions on where to look or what to
> > look for in tracking this one down, that might be helpful. It
> > would be a shame to get this close to a working build but end
> > up throwing in the towel on something like this!
> a quick guess is that a non-LSB library has been referenced
> somewhere in the build of QtNetwork, and lsbc++ turns that into 
> a static link, and it's this static linking to a library which has 
> been built in a newer environment which has bound in such a
> specific "internal" symbol reference.  
> There's not really a quick-and-easy way to check how this is
> happening, just grunt work.  We've added a number of symbols
> of this internal type to satisfy builds, but this one is
> "too new", being a GLIB_2.7 symbol, and LSB currently "stops
> at" GLIB_2.4, and so can't go in to 4.1, nor "backport" to 4.0.
> If you can find the place this happens we can think about how
> it could be avoided...

Thanks Mats. Turns out it was the OpenSSL libraries that were the culprits. I had them linking in statically for testing purposes but forgot that I had to build them non-LSB for the moment (the latest OpenSSL 1.0.0c version won't build with LSB compilers, at least not as released, and I know there have been plenty of discussions in the past about building LSB-compliant OpenSSL). I disabled SSL support in Qt for now and that is getting me past the __isoc99_sscanf() problem.


Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia

More information about the lsb-discuss mailing list