gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] timespec_str and test linking


From: Gary E. Miller
Subject: Re: [gpsd-dev] timespec_str and test linking
Date: Wed, 25 Sep 2019 09:44:38 -0700

Yo Greg!


I found this comment in test_gpsmm:

/*
 * We should get libgps_dump_state() from the client library, but
 * scons has a bug; we can't get it to add -lgps to the link line,
 * apparently because it doesn't honor parse_flags on a Program()
 * build of a C++ file.
 */

So you had it right and I had it wrong.  Adding -lgps is the fix, and
then some hacks can be removed.


On Wed, 25 Sep 2019 08:14:06 -0400
Greg Troxel <address@hidden> wrote:

> "Gary E. Miller" <address@hidden> writes:
> 
> > If turns out that libQgpsmm.so is libgps.so, but compiled
> > differently for Qt.  So linking in -lgps is not right.
> >
> > timespec_str is being linked into libQgpsmm.so.25.0.0:
> >
> > g++ -o libQgpsmm.so.25.0.0 -pthread -shared -Wl,-Bsymbolic
> > -Wl,-soname=libQgpsmm.so.25 qt-ais_json.os qt-bits.os
> > qt-gpsdclient.os qt-gps_maskdump.os qt-gpsutils.os qt-hex.os
> > qt-json.os qt-libgps_core.os qt-libgps_dbus.os qt-libgps_json.os
> > qt-libgps_shm.os qt-libgps_sock.os qt-netlib.os qt-os_compat.os
> > qt-rtcm2_json.os qt-rtcm3_json.os qt-shared_json.os
> > qt-timespec_str.os qt-libgpsmm.os -L. -lrt -lm -ldbus-1 -lbluetooth
> > -ldbus-1 -lQt5Network -lQt5Core
> >
> > As it should be because timespec_str.c is in qtobjects in SConstruct
> >
> > I can see it in there:
> >
> > # strings libQgpsmm.so.25.0.0 | fgrep timespec_s
> > timespec_str
> >
> > But it does not get found when linking the binary:
> >
> > g++ -o tests/test_qgpsmm -pthread tests/qt-test_gpsmm.o -L. -lQgpsmm
> > /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld:
> > ./ libQgpsmm.so: undefined reference to `timespec_str'  
> 
> C++ does "name mangling" to encode types into function names, to
> support overloading with different types.  Trouble when interworking
> with C is.. not unheard of.
> 
> In this case, timespec_str.o (and os) show the C name:
> 
> gdt 120 ~/SOFTWARE/GPSD/gpsd > nm -g timespec_str.o
>                  U snprintf
> 0000000000000000 T timespec_str
> 
> but the library is both missing it and bizarrely has a mangled name:
> 
> gdt 118 ~/SOFTWARE/GPSD/gpsd > nm -g libQgpsmm.so.25.0.0 |egrep
> timespec 000000000001aac3 T _Z12timespec_strPK8timespecPcm
> 00000000000103d4 T iso8601_to_timespec
>                  U timespec_str
> 000000000000fbc6 T timespec_to_iso8601
> 
> That seems to be because there is a qt- vesrion of the function that
> is mangled:
> 
> gdt 133 ~/SOFTWARE/GPSD/gpsd > nm -g qt-timespec_str.os 
>                  U _GLOBAL_OFFSET_TABLE_
> 0000000000000000 T _Z12timespec_strPK8timespecPcm
>                  U snprintf
> 
> 
> So the problem is probably using a C++ compiler to build
> qt-timespec_str.os, and the build logs confirms that Instead, I would
> suggest just linking the C-built object and not having a qt- prefix,
> as it isn't in C++ and doesn't use qt things.
> 
> An alternative,  a bit kludgy, is to wrap the decl of timespec_str in
> 
>   extern "C" {
> 
>   }
> 
> probably with #if gaurds around those lines.   But that appears to
> have been done where is is used, as the unmangled name appears.
> 
> 
> While most C is valid C++, it's different, and I think it's best to be
> clear about which is which, which means 1) using extern "C" linkage
> when including C header files in C++ programs and 2) using a C
> compiler for C.
> 
> 




RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgpwlyZSgNDfi.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]