[lsb-discuss] undefined reference to `__isoc99_sscanf

Wichmann, Mats D mats.d.wichmann at intel.com
Wed Dec 29 05:45:32 PST 2010


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...



More information about the lsb-discuss mailing list