[lsb-discuss] undefined reference to `__isoc99_sscanf

Craig Scott craig.scott at csiro.au
Wed Dec 29 14:11:33 PST 2010



On Thu, 30 Dec 2010 9:03:16 am Craig Scott wrote:
> 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.

Actually, it got me all the way to the end of a successful build. :)  Now to go back and find better workaround for the things I had to disable. :-P

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


More information about the lsb-discuss mailing list