Getting "undefined reference to" when using the lib for ARM, but not when compiling it - linux

For one of my Qt Embedded projects I'm using a external Qt lib called SMTPEmail. This lib needs to be compiled before being included into a project, something that I managed to do successfully both for Qt 4.8 ARM and for Desktop.
The problem I'm getting is that when I include the headers into my project and include the library in the .pro, the linker gives me
(path_to_libs)/libSMTPEmail.so: undefined reference to `QSslSocket::connectToHostEncrypted(QString const&, unsigned short, QFlags<QIODevice::OpenModeFlag>)'
(path_to_libs)/libSMTPEmail.so: undefined reference to `QSslSocket::QSslSocket(QObject*)'
collect2: ld returned 1 exit status
make: *** [re8k_interface-tgt] Error 1
but only for compiling for ARM. IOW compiling the lib for both ARM and Desktop goes OK, compiling the project for Desktop using the lib goes OK but compiling it for ARM using the lib goes wrong.
Following this forum thread I suspected this could be due to missing the link to the library file of openssl (the project points to different lib folders when compiling for different environments). So I searched for all "openssl" related files inside the compiler for ARM (arm-arago-linux-gnueabi) and included in the same folder where the .so is located; same error. I then suspected the lib itself had other dependencies which were not in the path_to_libs, so I did a readelf -d libSMTPEmail.so and later in the .so.1 and readelf did return some lib dependencies that were not inside the same folder of the library. I then copied all such dependencies to the folder and got no success either.
So what could be happening? All dependencies known by me were put in place and I still get the error only for the situation where the lib is included by another project compiled for ARM.

You need to point your QMake where your libs and header file is in your .pro file;
So find where your library is assume /usr/local/include then ;
INCLUDEPATH += /usr/local/include
Add which libs you will use;
LIBS += -lSMTPEmail
You can check my answer here;

Two things stand out for me in your question:
1.
undefined reference to
This error message means that there was an error in the linking step of compilation. This occurs when you include a header to a function/class/variable but don't have the definition included in your own sources, or you do not link in a static library that does.
Searching for dependencies in libraries that are already compiled (.dll or .so) is too late, the compiler is looking for a static link, not a dynamic link.
2.
compiling the lib for both ARM and Desktop goes OK, compiling the
project for Desktop using the lib goes OK but compiling it for ARM
using the lib goes wrong.
This suggests that you are using conditional compilation in your .pro file that does a "both" compilation, a "desktop only" compilation and a "ARM only" compilation. If this is correct, you need to examine your compilation instructions for your "ARM only" compilation.
The error message itself refers to you using two functions from the QSslStock class. These are part of the QtNetwork module so you should have the following in your .pro file in order for the necessary links to be formed.
Qt += network

Related

How to export lib incorporated with C dynllib?

Say, I have a lib package with a C shared library in a sub-directory. This rust library package compiles without errors, by means of tailored build.rs which sub-calls make in the sub-directory and then dynamicly links against the *.so product of make.
The problem arises when I try to link a binary package against this rust lib has the C shared lib within itself.
error: linking with `cc` failed: exit status: 1
= note: /usr/bin/ld: cannot find -lcuda_wrapper
collect2: error: ld returned 1 exit status
The dependency graph can be shown as the following one:
C-shared-lib < rust-lib < rust-bin
And cargo build fails to build rust-bin for not finding that C-shared-lib.
providing LD_LIBRARY_PATH for cargo build neither by command line nor build.rs within rust-bin facilitates the problem and lifts the error.
How to propagate the directory wherein resides libcuda_wrapper.so?
You can link your C library dynamically or statically.
In order to do that you can use add one of the following lines to your build.rs (note that you linkely won't need a lib prefix):
println!("cargo:rustc-link-lib=static=cuda_wrapper");
println!("cargo:rustc-link-lib=dylib=cuda_wrapper");
In order to define a search path, add this line to build.rs
println!("cargo:rustc-link-search=native={}", path);
You would likely want to add it to your rust-lib build.rs. Altenatively, you can create a build.rs for every executable which depends on rust-bin and add the same set of lines here.
It is a good idea to ensure that your C library build output is located under OUT_DIR env variable (you can get it using env::var("OUT_DIR").unwrap() in build.rs). The way cargo clean will work as expected as well.
More details here:
https://doc.rust-lang.org/cargo/reference/build-scripts.html#rustc-link-lib
https://doc.rust-lang.org/rustc/command-line-arguments.html#option-l-link-lib
https://doc.rust-lang.org/cargo/reference/build-script-examples.html#building-a-native-library
https://doc.rust-lang.org/cargo/reference/environment-variables.html

"undefined reference" error from static lib of external parquet project

I want to link expernal 'parquet' project ( https://github.com/apache/arrow/tree/master/cpp ) as part of my current project on Linux.
For this purposes I ran cmake of parquet with such parameters
cd build_parquet
cmake -DCMAKE_BUILD_TYPE=Release -DARROW_PARQUET=ON \
-DBoost_NO_BOOST_CMAKE=TRUE -DBoost_NO_SYSTEM_PATHS=TRUE -DBOOST_ROOT=${BOOST_BUILD_DIR}/include -DBOOST_LIBRARYDIR=${BOOST_BUILD_DIR}/lib/boost -DARROW_BOOST_USE_SHARED=OFF -DBOOST_INCLUDEDIR=${BOOST_BUILD_DIR}/include/boost ..
cmake --build . --config Release
// There are a lot of dependencies except boost, but only boost required to be installed on system, since other could be downloaded and installed by cmake script
Project successfully compiled. I got executable which could launch, generated static libs libarrow.a, libparquet.a, shared libraries libarrow.so, libparquet.so
In my main project I want to use such libraries and I use such commands in cmake to find them
find_path(PARQUET_INCLUDE_DIR NAMES arrow/api.h PATHS ${PARQUET_DIR}/src)
find_library(PARQUET_LIBRARY_RELEASE NAMES parquet.a
PATHS build_parquet/release/Release/ )
find_library(ARROW_LIBRARY_RELEASE NAMES arrow.a
PATHS build_parquet/release/Release/ )
set(PARQUET_LIBRARIES_RELEASE ${PARQUET_LIBRARY_RELEASE} ${ARROW_LIBRARY_RELEASE} )
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(Parquet DEFAULT_MSG PARQUET_INCLUDE_DIR
${PARQUET_LIBRARIES_RELEASE } )
That's work okay, libraries and includes are found.
Then I link this libraries to my project
target_link_libraries(${myExe} ${PARQUET_LIBRARIES_RELEASE} ${mySomeOtherLibraries} )
after this I got enormous amount of linker errors such that
libparquet.a(column_writer.cc.o): In function `apache::thrift::transport::TMemoryBuffer::~TMemoryBuffer()':
column_writer.cc:(.text._ZN6apache6thrift9transport13TMemoryBufferD0Ev[_ZN6apache6thrift9transport13TMemoryBufferD5Ev]+0x3): undefined reference to `vtable for apache::thrift::transport::TMemoryBuffer'
.....
so that's what I don't understand much, why lib compiled well in parquet project itself but has a lot of unresolved now, when I use it to link in my own project? Moreover I compiled project for windows and when I did the same things, but with arrow.lib and parquet.lib (instead of libparquet.a and libarrow.a ) things worked fine! I was needed only to put arrow.dll, parquet.dll to executables to run project. But in Linux I've already crashed my head
So, why it doesn't work, what I should do to finally link the project with library ?
Update
I found the problem, I had to link libraries with adding .so files (not only .a files) like this
find_library(PARQUET_LIBRARY_RELEASE NAMES parquet.so parquet.a
PATHS build_parquet/release/Release/ )
find_library(ARROW_LIBRARY_RELEASE NAMES arrow.so arrow.a
PATHS build_parquet/release/Release/ )
set(PARQUET_LIBRARIES_RELEASE ${PARQUET_LIBRARY_RELEASE} ${ARROW_LIBRARY_RELEASE} )
Project is builded. So now the question is, why I need to add .so files to linker (in Windows only static .lib are enough), is it always a case when I build project in Linux ? Is order of linkage important ( .so files first and .a files next ? )
As Uwe wrote in a comment, the https://github.com/apache/parquet-cpp repository is deprecated, and the Parquet C++ library is being developed as part of the Apache Arrow C++ codebase https://github.com/apache/arrow/tree/master/cpp. Can you try building based on that, and if you have trouble can you post on the dev#arrow.apache.org mailing list?
You have succeed to build the project when link with the shared (.so) libraries instead of the static (.a) ones.
(The command find_library actually looks for one library, which name is listed in NAMES option. In your case it found .so library because its name comes before the .a one).
Actually, both shared and static parquet libraries contain the same set of symbols, and both sets are insufficient for link. The difference is that the shared library contains information, where to find remaining symbols (in the thrift library in your case), but the static library doesn't.
For correctly link with the static libraries, you need to list dependent libraries manually.
On Windows .lib file may mean either a static library, or a import file for the shared (.dll) one. It seems that you link with the dynamic one (it has no lib prefix), which succeed like on Linux.

linking against library using VS and CMake on windows

I'm new to the world of cmake and linking to libaries. Now for a project I need to include a third party library in the current application. However I'm having problems linking to the library.
Here is what I have:
The library is build in the location D:/qwt-6.1.2, which contains:
the folder /src with the header and source files
the folder /lib which contains (qwt.dll, qwt.ext, qwt.lib, qwtd.dll, qwtd.ext, qwtd.ilk, qwtd.lib and qwtd.pdb.
I have tried to add the following to the cmake file:
add_executable(Demo main.cpp mainwindow.cpp mainwindow.h )
include_directories(D:/qwt-6.1.2/src)
link_directories(D:/qwt-6.1.2/lib)
target_link_libraries(Demo qwt)
The including goes fine since the intellisense of visual studio can the includes that I do, however when I build I get the error:
Error 1 error LNK1104: cannot open file 'qwt.lib'
Does anybody have an idea what I'm doing wrong? I don't care at the moment if it is statically or dynamically linked.

crt1.o: In function `_start': - undefined reference to `main' in Linux

I am porting an application from Solaris to Linux
The object files which are linked do not have a main() defined. But compilation and linking is done properly in Solaris and executable is generated. In Linux I get this error
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
My problem is, I cannot include new .c/.o files since its a huge application and has been running for years. How can I get rid of this error?
Code extractes of makefile:
RPCAPPN = api
LINK = cc
$(RPCAPPN)_server: $(RPCAPIOBJ)
$(LINK) -g $(RPCAPIOBJ) -o $(RPCAPPN)_server $(IDALIBS) $(LIBS) $(ORALIBS) $(COMMONLIB) $(LIBAPI) $(CCLIB) $(THREADLIB) $(DBSERVERLIB) $(ENCLIB)
Try adding -nostartfiles to your linker options, i.e.
$(LINK) -nostartfiles -g ...
From the gcc documentation:
-nostartfiles
Do not use the standard system startup files when linking. The standard system libraries are used normally, unless -nostdlib or -nodefaultlibs is used.
This causes crt1.o not to be linked (it's normally linked by default) - normally only used when you implement your own _start code.
-shared link option must be used when you compile a .so
The issue for me was, I by mistake put int main() in a namespace. Make sure don't do that otherwise you will get this annoying link error.
Hope this helps anyone :)
I had similar result when trying to build a new test project with boost, and it turned out that I was missing one declaration :
#define BOOST_TEST_MODULE <yourtestName>
I had this same problem when creating my c project, and I forgot to save my main.c file, so there was no main function.
I had a similar result when compiling a Fortran program that had C++ components linked in. In my case, CMake failed to detect that Fortran should be used for the final linking. The messages returned by make then ended with
[100%] Linking CXX executable myprogram
/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
make[3]: *** [myprogram] Error 1
make[2]: *** [CMakeFiles/myprogram.dir/all] Error 2
make[1]: *** [CMakeFiles/myprogram.dir/rule] Error 2
make: *** [myprogram] Error 2
The solution was to add
set_target_properties(myprogram PROPERTIES LINKER_LANGUAGE Fortran)
to the CMakeLists.txt, so that make prints out:
[100%] Linking Fortran executable myprogram
[100%] Built target myprogram
I had the same issue with a large CMake project, after I moved some functions from one code file to another. I deleted the build folder, recreated it and rebuilt. Then it worked.
Generally, with suddenly appearing linker errors, try completely deleting your build folder and rebuilding first. That can save you the headaches from trying to hunt down an error that actually simply shouldn't be there: There might be CMake cache variables floating around that have the wrong values, or something was renamed and not deleted, ...
I had the same issue as to OP but on on FreeBSD 13.1.
What solved the issue was simply adding:
int main()
{
}
Since the .cpp file was only an object file containing definitions and declarations using:
extern "C"
{
<all definitions and declarations code goes here>
}
Every time I tried compiling this, the compiler kept throwing the same error as to OP.
So all I did was add an empty main() function all the way at the bottom and code compiled with no errors.

CMake finds the correct library, but VC++ attempts to link with something else

I have a CMake module to locate FreeGLUT:
FIND_PATH(FREEGLUT_INCLUDE_DIR NAMES GL/freeglut.h)
FIND_LIBRARY(FREEGLUT_LIBRARY NAMES freeglut freeglut_static)
SET(FREEGLUT_LIBRARIES ${FREEGLUT_LIBRARY})
SET(FREEGLUT_INCLUDE_DIRS ${FREEGLUT_INCLUDE_DIR})
INCLUDE(FindPackageHandleStandardArgs)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(FreeGLUT DEFAULT_MSG FREEGLUT_LIBRARY FREEGLUT_INCLUDE_DIR)
MARK_AS_ADVANCED(FREEGLUT_INCLUDE_DIR FREEGLUT_LIBRARY)
It works fine and locates freeglut_static.lib when I generate NMake Makefiles on Windows. I'm attempting to statically link FreeGLUT into my DLL:
FIND_PACKAGE(FreeGLUT REQUIRED)
ADD_LIBRARY(vti SHARED ${VTI_SOURCES})
ADD_DEFINITIONS("-DBUILD_VTI=1 -DFREEGLUT_STATIC=1")
INCLUDE_DIRECTORIES(${CMAKE_SOURCE_DIR}/include ${FREEGLUT_INCLUDE_DIRS})
TARGET_LINK_LIBRARIES(vti ${FREEGLUT_LIBRARIES})
My source code builds correctly, but when it gets to the linking stage, VC++ fails with:
LINK : fatal error LNK1104: cannot open file 'freeglut.lib'
Which is strange since freeglut.lib isn't mentioned anywhere that I can see in the generated NMake makefiles. It should be trying to link with freeglut_static.lib, which CMake locates and sets in FREEGLUT_LIBRARIES.
What might be causing this?
This is caused with pragma directives in FreeGLUT code (see freeglut_std.h). Using FREEGLUT_STATIC should really fix that for you, but I think you should pass it to CMake without quotes: ADD_DEFINITIONS(-DBUILD_VTI -DFREEGLUT_STATIC)

Resources