Linking libraries - follow-up- gcc++ won't link
-
Hope it is OK to make new post. I am still working on this assumption:
other
An object file to be fed straight into linking. Any file name with no recognized suffix is treated this way.Adding full path to desired library to be added to existing library resolved the "cannot find " issue. Now the gcc++ needs to be told to actually link, contrary to the "other" instruction taken from Linux documentation. I get same error when using libbluetooth.a.
'MODULE/M_TEST/CTEST.o' '-o' 'MODULE/M_TEST/CTEST.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
Finished building: ../MODULE/M_TEST/CTEST.cppg++: warning: /usr/lib/x86_64-linux-gnu/bluetooth: linker input file unused because linking not done
Building file: ../MODULE/M_SOCKET/CSOCKETCOMMON.cpp
Invoking: GCC C++ Compiler -
Hope it is OK to make new post. I am still working on this assumption:
other
An object file to be fed straight into linking. Any file name with no recognized suffix is treated this way.Adding full path to desired library to be added to existing library resolved the "cannot find " issue. Now the gcc++ needs to be told to actually link, contrary to the "other" instruction taken from Linux documentation. I get same error when using libbluetooth.a.
'MODULE/M_TEST/CTEST.o' '-o' 'MODULE/M_TEST/CTEST.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
Finished building: ../MODULE/M_TEST/CTEST.cppg++: warning: /usr/lib/x86_64-linux-gnu/bluetooth: linker input file unused because linking not done
Building file: ../MODULE/M_SOCKET/CSOCKETCOMMON.cpp
Invoking: GCC C++ Compiler -
Hope it is OK to make new post. I am still working on this assumption:
other
An object file to be fed straight into linking. Any file name with no recognized suffix is treated this way.Adding full path to desired library to be added to existing library resolved the "cannot find " issue. Now the gcc++ needs to be told to actually link, contrary to the "other" instruction taken from Linux documentation. I get same error when using libbluetooth.a.
'MODULE/M_TEST/CTEST.o' '-o' 'MODULE/M_TEST/CTEST.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
Finished building: ../MODULE/M_TEST/CTEST.cppg++: warning: /usr/lib/x86_64-linux-gnu/bluetooth: linker input file unused because linking not done
Building file: ../MODULE/M_SOCKET/CSOCKETCOMMON.cpp
Invoking: GCC C++ CompilerSome very odd things here:
Vaclav_ wrote:
'MODULE/M_TEST/CTEST.o' '-o' 'MODULE/M_TEST/CTEST.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
That looks wrong. That looks like your compiler command could be boiled down to
g++ CTEST.o -o CTEST.o
You're passing in and producing the same .o file, not creating an executable, only an intermediate object. In which case the g++ warning makes sense, since its telling you that the lib wasn't used to create the .o file. In which case you should be getting a g++ fatal error input file is same as output file. Second thing is the warning itself. The path given is /usr/lib/x86_64-linux-gnu/bluetooth. Normally that would be libbluetooth.a. In which case the linker should be able to pick it up as -lbluetooth, since its in the expected location. It just doesn't have a name format that the linker recognizes as a library. I'd say say something messed up when installing the library, if this is indeed the case and you've not just messed up copying the output from your system to the forum.
-
Hope it is OK to make new post. I am still working on this assumption:
other
An object file to be fed straight into linking. Any file name with no recognized suffix is treated this way.Adding full path to desired library to be added to existing library resolved the "cannot find " issue. Now the gcc++ needs to be told to actually link, contrary to the "other" instruction taken from Linux documentation. I get same error when using libbluetooth.a.
'MODULE/M_TEST/CTEST.o' '-o' 'MODULE/M_TEST/CTEST.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
Finished building: ../MODULE/M_TEST/CTEST.cppg++: warning: /usr/lib/x86_64-linux-gnu/bluetooth: linker input file unused because linking not done
Building file: ../MODULE/M_SOCKET/CSOCKETCOMMON.cpp
Invoking: GCC C++ Compiler -
As already noted by k5054, you (
-ooption) are asking theg++to NOT perform the linking step. Nevermind. (thanks to k5054)Oops, Ha Ha, actually, we both got that wrong. The compiler is quite happy to link an executable into a file named foo.o e.g.
$ g++ hello.cpp -o hello.o
$ ./hello.o
Hello World!
$Its the
-coption that compiles but does not link, so that must have been included in the command sent to the compiler. -
Hope it is OK to make new post. I am still working on this assumption:
other
An object file to be fed straight into linking. Any file name with no recognized suffix is treated this way.Adding full path to desired library to be added to existing library resolved the "cannot find " issue. Now the gcc++ needs to be told to actually link, contrary to the "other" instruction taken from Linux documentation. I get same error when using libbluetooth.a.
'MODULE/M_TEST/CTEST.o' '-o' 'MODULE/M_TEST/CTEST.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
Finished building: ../MODULE/M_TEST/CTEST.cppg++: warning: /usr/lib/x86_64-linux-gnu/bluetooth: linker input file unused because linking not done
Building file: ../MODULE/M_SOCKET/CSOCKETCOMMON.cpp
Invoking: GCC C++ CompilerStand-by. I build some more test apps and "discovered" that type .so library has STANDARD IDE options for linker , but type .a , which I have been messing with, does NOT. Also neither one of them show -l option, only -L. Basically - forget IDE, back to GCC raw options.
-
Stand-by. I build some more test apps and "discovered" that type .so library has STANDARD IDE options for linker , but type .a , which I have been messing with, does NOT. Also neither one of them show -l option, only -L. Basically - forget IDE, back to GCC raw options.
Vaclav_ wrote:
type .so library has STANDARD IDE options for linker , but type .a , which I have been messing with, does NOT.
That makes no sense, there are no such things as standard IDE options for compiling and/or linking. The options are determined by the specific compiler and linker in use. You may have an IDE that is set up to use the most common options for gcc, but you still need to modify it depending whether you are trying to create a static archive (.a), or shared object library (.so).
-
Oops, Ha Ha, actually, we both got that wrong. The compiler is quite happy to link an executable into a file named foo.o e.g.
$ g++ hello.cpp -o hello.o
$ ./hello.o
Hello World!
$Its the
-coption that compiles but does not link, so that must have been included in the command sent to the compiler. -
Hope it is OK to make new post. I am still working on this assumption:
other
An object file to be fed straight into linking. Any file name with no recognized suffix is treated this way.Adding full path to desired library to be added to existing library resolved the "cannot find " issue. Now the gcc++ needs to be told to actually link, contrary to the "other" instruction taken from Linux documentation. I get same error when using libbluetooth.a.
'MODULE/M_TEST/CTEST.o' '-o' 'MODULE/M_TEST/CTEST.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
Finished building: ../MODULE/M_TEST/CTEST.cppg++: warning: /usr/lib/x86_64-linux-gnu/bluetooth: linker input file unused because linking not done
Building file: ../MODULE/M_SOCKET/CSOCKETCOMMON.cpp
Invoking: GCC C++ CompilerPost-mortem FYI SOLVED(?) 1.Both projects ( IDE terminology) works as expected. NOT REALLY SURE WHY. 2.The “mother” executable - project has -lbluetooth -lRPI_BT_LIB, but ONLY -L "${workspace_loc:/RPI_BT_LIB/Debug}" optioned. 3. There are NO references / options to “bluetooth” in RPI_BT_LIB, only source includes. 3. Adding “bluetooth” as per this ( no -l or -L !) other An object file to be fed straight into linking. Any file name with no recognized suffix is treated this way. Creates “cannot find ...” error 4. Adding “/usr/…/bluetooth” creates “ did not link ...” error but has no effect on processing. (It was pointed out that GCC was not optioned to link ) 5. running “make clear” idefinites full library file name - “libRPI_RT_LIB.a” 6. Using “standard IDE” ( I am calling IDE UI form "standard" ) to build type .a library gives NO linking options, however building .so gives ALL options. 7. Using “standard IDE form” to build a project – executable or library – creates “system” default includes. NOT sure if they are used only for source or linking libraries. As far as I can tell this whole mess was because I could not tell if I was using wrong GCC options or wrong syntax It was NEVER about (-l / -L ). The unanswered question remains - how does the RPI_BT_LIB library manages to use "bluetooth" library.
-
Post-mortem FYI SOLVED(?) 1.Both projects ( IDE terminology) works as expected. NOT REALLY SURE WHY. 2.The “mother” executable - project has -lbluetooth -lRPI_BT_LIB, but ONLY -L "${workspace_loc:/RPI_BT_LIB/Debug}" optioned. 3. There are NO references / options to “bluetooth” in RPI_BT_LIB, only source includes. 3. Adding “bluetooth” as per this ( no -l or -L !) other An object file to be fed straight into linking. Any file name with no recognized suffix is treated this way. Creates “cannot find ...” error 4. Adding “/usr/…/bluetooth” creates “ did not link ...” error but has no effect on processing. (It was pointed out that GCC was not optioned to link ) 5. running “make clear” idefinites full library file name - “libRPI_RT_LIB.a” 6. Using “standard IDE” ( I am calling IDE UI form "standard" ) to build type .a library gives NO linking options, however building .so gives ALL options. 7. Using “standard IDE form” to build a project – executable or library – creates “system” default includes. NOT sure if they are used only for source or linking libraries. As far as I can tell this whole mess was because I could not tell if I was using wrong GCC options or wrong syntax It was NEVER about (-l / -L ). The unanswered question remains - how does the RPI_BT_LIB library manages to use "bluetooth" library.
Vaclav_ wrote:
how does the RPI_BT_LIB library manages to use "bluetooth" library.
The same way that any code uses any library. Define the external references and add the library to the build process. Take a look at gcc library - Google Search[^] for more detailed information.
