linker cannot find shared library...
-
Salvatore Terress wrote:
when the SOURCE is added AS INTERNAL LIBRARY , it builds fine BUT the linker has no info where,,,
That makes no sense. The linker uses the provided information to build the final executable, and if a library file cannot be located you would see link errors in the build. You still need to ensure that the library can be located at run time by the system loader, just as k5054 describes.
Actually, it does make sense. For example, suppose I have /usr/local/project/lib/libfoo.so When I compile I use
g++ project.c -L /usr/local/project/lib -l foo -o project
That will compile just fine, the compiler knows to look in /usr/local/project/lib to find the shared library to do its magic to create an executable. Unless I've told the link-loader to check /usr/local/projec/lib, when I try to run it I'll get the message about not being able to find the library.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
-
Actually, it does make sense. For example, suppose I have /usr/local/project/lib/libfoo.so When I compile I use
g++ project.c -L /usr/local/project/lib -l foo -o project
That will compile just fine, the compiler knows to look in /usr/local/project/lib to find the shared library to do its magic to create an executable. Unless I've told the link-loader to check /usr/local/projec/lib, when I try to run it I'll get the message about not being able to find the library.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
-
Salvatore Terress wrote:
could help me to resolve this issue?...linker
In your post there is nothing that suggests this is a "linker" problem. Code development parts 1. Write code 2. Compile code, which includes linking. 3. Run code. What you posted is 3. Not 2. So you have an executable binary. It runs. The executable and OS together attempt to load libraries requested by the binary. It is not finding them. So as per the other post, in linux/unix there are various ways to provide that information to the OS to do that job. By providing a 'library path'. Your question references "QT". Not sure what that is but guessing you are referring to 'QT Creator'. And you are, perhaps, running it in the IDE. If so the steps above still apply. The only difference is that in 'QT Creator' there is going to be an option somewhere that allows you to specify one or more 'library paths'. Getting the format of that correct is not often simple to figure out in my experience. That is because determining a separator is not obvious. But perhaps QA Creator allows (forces) you to add one at a time. Keep in mind that when you deliver your binary you MUST deal with the same issue. And that will NOT be a QT Creator problem nor question.
in another words HOW the QT (IDE) presents the name of the library ( it did find it as expected, the path to it is known to it... ) in an option box and when finished the compiler / linker builds the .so files . These .so files are , with little patience, visible in compiler/ linker output. What remains is to find , as noted , WHY the result is another folder / directory inserted in code...structure Where in the QT IDE is the option controlling that and why the run process (?) cannot find the build / constructed .so files
-
in another words HOW the QT (IDE) presents the name of the library ( it did find it as expected, the path to it is known to it... ) in an option box and when finished the compiler / linker builds the .so files . These .so files are , with little patience, visible in compiler/ linker output. What remains is to find , as noted , WHY the result is another folder / directory inserted in code...structure Where in the QT IDE is the option controlling that and why the run process (?) cannot find the build / constructed .so files
Note: you do not need to use bold text, we are all quite capable of reading normal font. As to your questions:
Salvatore Terress wrote:
Where in the QT IDE is the option controlling that (another folder / directory inserted in code...structure )
No idea, this is the C++ forum, you need to ask in the QT support site.
Salvatore Terress wrote:
why the run process (?) cannot find the build / constructed .so files
As we have explained before, the system loader has a set of predefined locations which it searches for shared object libraries when the program runs. If your library is not within one of these directories then you need to add its location to the
LD_LIBRARY_PATHenvironment variable. -
in another words HOW the QT (IDE) presents the name of the library ( it did find it as expected, the path to it is known to it... ) in an option box and when finished the compiler / linker builds the .so files . These .so files are , with little patience, visible in compiler/ linker output. What remains is to find , as noted , WHY the result is another folder / directory inserted in code...structure Where in the QT IDE is the option controlling that and why the run process (?) cannot find the build / constructed .so files
Salvatore Terress wrote:
why the run process (?) cannot find the build
Doesn't help you solve the problem but maybe it will make you feel better... I have been doing this for decades and these specific sorts of problems are always frustrating. I have used make files, maven files, three different IDEs with multiple versions (probably 10 of VS) and even a couple of times custom built build tools. And figuring out how the specific build processes resolves stuff always involves experimentation.
Salvatore Terress wrote:
WHY the result is another folder / directory inserted in code...structure
As a suggestion don't focus on that. If you can figure out a solution where you manually modify it and it works then go with that. Keep in mind that include is stupid so maybe it works for you to add a second include line after the one it attempts to use with the correct path.
-
Salvatore Terress wrote:
why the run process (?) cannot find the build
Doesn't help you solve the problem but maybe it will make you feel better... I have been doing this for decades and these specific sorts of problems are always frustrating. I have used make files, maven files, three different IDEs with multiple versions (probably 10 of VS) and even a couple of times custom built build tools. And figuring out how the specific build processes resolves stuff always involves experimentation.
Salvatore Terress wrote:
WHY the result is another folder / directory inserted in code...structure
As a suggestion don't focus on that. If you can figure out a solution where you manually modify it and it works then go with that. Keep in mind that include is stupid so maybe it works for you to add a second include line after the one it attempts to use with the correct path.
Part of my frustration is the code compiles , builds the library, and DOES NOT complains about the library #include (code) in source - where the library will be used... the only error is when "run" and the .so cannot be found.. I am still looking for "low level compiler / linker options" - somewhere in QT configuration and can see some in compiler /linker output
-
Part of my frustration is the code compiles , builds the library, and DOES NOT complains about the library #include (code) in source - where the library will be used... the only error is when "run" and the .so cannot be found.. I am still looking for "low level compiler / linker options" - somewhere in QT configuration and can see some in compiler /linker output
In case somebody is still interested in resolving / discussing this I understand the "rm " , however it appears there in no need of knowledge / control from WHERE to remove valid .so build in first place. then gcc proceeds to build the .so in " /home/nov25-1/Qt/5.15.2/ ..." Since Qt changes as often as mine socks I am not sure its -gcc-_ selection of final resting place of .so files is OK. IMHO .so should be part of the project structure - outside Qt. Here is what compiler /linker outputs when I "rebuild" the library .pro project.
rm -f libBluetoothctl_Dialog.so.1.0.0 libBluetoothctl_Dialog.so libBluetoothctl_Dialog.so.1 libBluetoothctl_Dialog.so.1.0
clang++ -ccc-gcc-name g++ -Wl,-rpath,/home/nov25-1/Qt/5.15.2/gcc_64/lib -shared -Wl,-soname,libBluetoothctl_Dialog.so.1 -o libBluetoothctl_Dialog.so.1.0.0 main.o mainwindow_bluewtoothctl_dialog.o moc_mainwindow_bluewtoothctl_dialog.o /home/nov25-1/Qt/5.15.2/gcc_64/lib/libQt5Widgets.so /home/nov25-1/Qt/5.15.2/gcc_64/lib/libQt5Gui.so /home/nov25-1/Qt/5.15.2/gcc_64/lib/libQt5Core.so -lGL -lpthread
ln -s libBluetoothctl_Dialog.so.1.0.0 libBluetoothctl_Dialog.so
ln -s libBluetoothctl_Dialog.so.1.0.0 libBluetoothctl_Dialog.so.1
ln -s libBluetoothctl_Dialog.so.1.0.0 libBluetoothctl_Dialog.so.1.0
14:38:10: The process "/usr/bin/make" exited normally.
14:38:10: Elapsed time: 00:16. -
In case somebody is still interested in resolving / discussing this I understand the "rm " , however it appears there in no need of knowledge / control from WHERE to remove valid .so build in first place. then gcc proceeds to build the .so in " /home/nov25-1/Qt/5.15.2/ ..." Since Qt changes as often as mine socks I am not sure its -gcc-_ selection of final resting place of .so files is OK. IMHO .so should be part of the project structure - outside Qt. Here is what compiler /linker outputs when I "rebuild" the library .pro project.
rm -f libBluetoothctl_Dialog.so.1.0.0 libBluetoothctl_Dialog.so libBluetoothctl_Dialog.so.1 libBluetoothctl_Dialog.so.1.0
clang++ -ccc-gcc-name g++ -Wl,-rpath,/home/nov25-1/Qt/5.15.2/gcc_64/lib -shared -Wl,-soname,libBluetoothctl_Dialog.so.1 -o libBluetoothctl_Dialog.so.1.0.0 main.o mainwindow_bluewtoothctl_dialog.o moc_mainwindow_bluewtoothctl_dialog.o /home/nov25-1/Qt/5.15.2/gcc_64/lib/libQt5Widgets.so /home/nov25-1/Qt/5.15.2/gcc_64/lib/libQt5Gui.so /home/nov25-1/Qt/5.15.2/gcc_64/lib/libQt5Core.so -lGL -lpthread
ln -s libBluetoothctl_Dialog.so.1.0.0 libBluetoothctl_Dialog.so
ln -s libBluetoothctl_Dialog.so.1.0.0 libBluetoothctl_Dialog.so.1
ln -s libBluetoothctl_Dialog.so.1.0.0 libBluetoothctl_Dialog.so.1.0
14:38:10: The process "/usr/bin/make" exited normally.
14:38:10: Elapsed time: 00:16.Clearly the QT IDE (QTCreator?) does a cd to some sort of project target directory before starting the build process, which may be different for a Debug build and a Release build. Like just about everybody else here, I don't do QT, and since your questions are more to do with QT and it's related tools than with C++ per se, you should probably ask your questions in a QT related forum. It looks like, for some reason, you're using clang++ rather than g++ to compile. There's nothing wrong with that. It's just that the compiler argument
-ccc-gcc-name g++seems to suggest that you've somehow triggered cross compilation. Maybe. I really do not know. Googling for "clang -ccc-gcc-name" gets hits for cross-compiling. So you may have misconfigured your build environment. Or Not. You'd really have to ask someone who knows the QT IDE. This fragment seems to be building a shared library, as evidenced by the the-sonmeargument, the.sooutput file suffix, the output basename starting withlib, and the last 3 commands that create the .so links. But here is also amain.obeing included in the target. Now there's nothing to say that a source filemain.cppmust definemain(), but I think most people would be expecting it. Assuming that you are trying to create a librarry, then f you do definemain()in your main.cpp, then I would definitely consider that an error. That would mean that when you try to link that library into some other program, you'd end up with 2mainentry points, which I would expect the linker to flag as an error [weak symbols notwithstanding (google is your friend )]. Alternatively, maybe you are intending to produce an executable, and not a shared library. In which case, you've definitely made some mistakes configuring your target in the IDE. So at the very least, I think you need to re-examine your IDE settings and see if you're actually doing what you think you're doing."A little song, a little dance, a little seltzer down your pants" Chuckles the clown
-
In case somebody is still interested in resolving / discussing this I understand the "rm " , however it appears there in no need of knowledge / control from WHERE to remove valid .so build in first place. then gcc proceeds to build the .so in " /home/nov25-1/Qt/5.15.2/ ..." Since Qt changes as often as mine socks I am not sure its -gcc-_ selection of final resting place of .so files is OK. IMHO .so should be part of the project structure - outside Qt. Here is what compiler /linker outputs when I "rebuild" the library .pro project.
rm -f libBluetoothctl_Dialog.so.1.0.0 libBluetoothctl_Dialog.so libBluetoothctl_Dialog.so.1 libBluetoothctl_Dialog.so.1.0
clang++ -ccc-gcc-name g++ -Wl,-rpath,/home/nov25-1/Qt/5.15.2/gcc_64/lib -shared -Wl,-soname,libBluetoothctl_Dialog.so.1 -o libBluetoothctl_Dialog.so.1.0.0 main.o mainwindow_bluewtoothctl_dialog.o moc_mainwindow_bluewtoothctl_dialog.o /home/nov25-1/Qt/5.15.2/gcc_64/lib/libQt5Widgets.so /home/nov25-1/Qt/5.15.2/gcc_64/lib/libQt5Gui.so /home/nov25-1/Qt/5.15.2/gcc_64/lib/libQt5Core.so -lGL -lpthread
ln -s libBluetoothctl_Dialog.so.1.0.0 libBluetoothctl_Dialog.so
ln -s libBluetoothctl_Dialog.so.1.0.0 libBluetoothctl_Dialog.so.1
ln -s libBluetoothctl_Dialog.so.1.0.0 libBluetoothctl_Dialog.so.1.0
14:38:10: The process "/usr/bin/make" exited normally.
14:38:10: Elapsed time: 00:16. -
Clearly the QT IDE (QTCreator?) does a cd to some sort of project target directory before starting the build process, which may be different for a Debug build and a Release build. Like just about everybody else here, I don't do QT, and since your questions are more to do with QT and it's related tools than with C++ per se, you should probably ask your questions in a QT related forum. It looks like, for some reason, you're using clang++ rather than g++ to compile. There's nothing wrong with that. It's just that the compiler argument
-ccc-gcc-name g++seems to suggest that you've somehow triggered cross compilation. Maybe. I really do not know. Googling for "clang -ccc-gcc-name" gets hits for cross-compiling. So you may have misconfigured your build environment. Or Not. You'd really have to ask someone who knows the QT IDE. This fragment seems to be building a shared library, as evidenced by the the-sonmeargument, the.sooutput file suffix, the output basename starting withlib, and the last 3 commands that create the .so links. But here is also amain.obeing included in the target. Now there's nothing to say that a source filemain.cppmust definemain(), but I think most people would be expecting it. Assuming that you are trying to create a librarry, then f you do definemain()in your main.cpp, then I would definitely consider that an error. That would mean that when you try to link that library into some other program, you'd end up with 2mainentry points, which I would expect the linker to flag as an error [weak symbols notwithstanding (google is your friend )]. Alternatively, maybe you are intending to produce an executable, and not a shared library. In which case, you've definitely made some mistakes configuring your target in the IDE. So at the very least, I think you need to re-examine your IDE settings and see if you're actually doing what you think you're doing."A little song, a little dance, a little seltzer down your pants" Chuckles the clown