|
Yes I see what you're saying. The only kind of dependency that I am familiar with is the static kind used by DLLs.
What kind of dependency are you discussing?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I have seen that also. Annoying when it showed up an I always ignored it without considering the reason why.
|
|
|
|
|
Seems like an interesting question.
Googling I found nothing that answers that.
From the other post I did find a comment in 'Dependency Walker' but that only stated that it occurred but not why.
Maybe you could determine the cause by looking at the detailed process information and comparing them?
|
|
|
|
|
Thanks for your responses.
I wish I had a line to Mark Russinovich. I'm sure he would know.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I wonder if somebody could help me to resolve this issue?
If so I be happy to provide details,, however, this is the issue in nutshell...
My code complies - no errors , but when I try "Run" this is my error:
<pre>/mnt/usb-Seagate_Expansion_NA833BDC-0:0-part4/BT__PROGRAMS/FT857_DEC11/BT_LIBRARY/mdi/mdi: error while loading shared libraries: libBT_Utility_Library.so.1: cannot open shared object file: No such file or directory
Press <RETURN> to close this window...
That tells me my "link / reference " to the library is wrong...
I posted same request in another forum and getting nowhere...
I would post a compiler output if it helps.
THANKS
|
|
|
|
|
Assuming Linux:
1: Tell the linker where to look for the library using LD_LIBRARY_PATH
$ LD_LIBRARY_PATH=$HOME/project1/lib:$HOME/project2/lib project3/bin/program
alternatively, you can export LD_LIBRARY_PATH:
$ export LD_LIBRARY_PATH=$HOME/project1/lib:$HOME/project2/lib
$ project3/bin/program1
$ project3/bin/program2 If you are going to be using it a lot, you may want to add the export to your shells init scripts. For bash, that would either be $HOME/.bash_profile, or $HOME/.bashrc Other shell programs use different init scripts - sometimes called rc (or .rc) scripts
2: you can use the linker option -Wl,-rpath=$HOME/project1/lib at compile time, which will add "magic" to the executable, so it knows where to look for the library. I've not used this to specify how to check more than one directory. I expect that -Wl,-rpath=location1 -Wl,-rpath=location2 will work, but you'll have to do some research to find out. You'd use this like
$ gcc file1.c file2.c file3.c -o program -Wl,-rpath=project/lib Check with your IDE on how you might change CFLAGS, or LDFLAGS
3: If you have root, you can add the library locations on a more permanent basis by adding to /etc/ld.so.conf.d
These files are just text files that list additional places for the linker to look. Assuming that you have your libraries in /home/user/project/lib then /etc/ld.so.conf.d/project would just contain the single line /home/user/project/lib. After creating that file, you need to remember to run ldconfig, as root, so the system updates its list of places to look. After that, when you launch your program, the linker should be able to find the necessary libraries.
You can check that you've got things covered by using the program ldd. This will list all the shared libraries a given program uses, and where they are located. If a given library can not be found ldd output shows "not found"
[k5054@localhost]$ ldd /usr/bin/vim
linux-vdso.so.1 (0x00007ffefb5e4000)
libm.so.6 => /lib64/libm.so.6 (0x00007fc6a2520000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fc6a2a9c000)
libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007fc6a2a68000)
libsodium.so.23 => /lib64/libsodium.so.23 (0x00007fc6a2a0f000)
libacl.so.1 => /lib64/libacl.so.1 (0x00007fc6a2516000)
libgpm.so.2 => /lib64/libgpm.so.2 (0x00007fc6a250e000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc6a232f000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc6a2ae7000)
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007fc6a2292000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007fc6a228a000)
[k5054@localhost]$
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
I appreciate your reply, unfortunately, I am using QT to build the project, hence i do not pay much attention to compiler / linker options...
for simple selfish reason - since it does the job most of the time...
Here is the latest
I have made an error "add libabry" (IDE option) SOURCE CODE by adding it as "internal" library
For time beeing I wont wont elaborate what QT calls "internal library"...
HOWEVER
when ADDED as "external library " (QT makes note it is NOT part of "regular build process ' (??)
I was lead to add .so file BUT such file was NOT located in project structure ( not part regular build process ??)
adding it as .so makes sense , however , QT build .so in ENTIRELY different folder !
and THAT is I BELIEVE CAUSED THE WHOLE ISSUE
HENCE
when the SOURCE is added AS INTERNAL LIBRARY , it builds fine BUT the linker has no info where,,,
|
|
|
|
|
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
|
|
|
|
|
I thought that's what I said. 
|
|
|
|
|
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.
|
|
|
|
|
jschell wrote: 2. Compile code, which includes linking.
Not strictly true. And I have tried to explain to the OP a number of times why that is so.
|
|
|
|
|
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_PATH environment variable.
modified 14-Dec-23 7:35am.
|
|
|
|
|
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
|
|
|
|
|
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 -sonme argument, the .so output file suffix, the output basename starting with lib, and the last 3 commands that create the .so links. But here is also a main.o being included in the target. Now there's nothing to say that a source file main.cpp must define main(), but I think most people would be expecting it. Assuming that you are trying to create a librarry, then f you do define main() 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 2 main entry 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
|
|
|
|
|
I do appreciate your comments, especially about QT.
However, since my comments are not received well...let sleeping dogs sleep..
Have a swell day.
|
|
|
|
|
None of that is the responsibility of the GNU compiler/linker. They (compiler/linker) will store the object files wherever you tell them. So the reason they are stored where they are is down to the project/makefile settings used to run the build.
|
|
|
|
|
I have never add #include using full path.
My code is obviously missing something
and the error ( file not found ) is not helping much to fix it.
Help will be greatly appreciated.
#include "/media/nov25-1/MDI_BACKUP_DEC10/BLUETOOTH/BT_LIBRARY/CCC_SOURCE/Bluetoothctl_Dialog/mainwindow_bluewtoothctl_dialog.h"
|
|
|
|
|
You keep saying "full path", but your example never starts with a drive letter, so taht would be a good place to start.
|
|
|
|
|
That seems like a full Linux path to me
Mircea
|
|
|
|
|
Could be. That's what I get for making an assumption of Windows.
|
|
|
|
|
... and a removable one at that! 
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
