|
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
|
|
|
|
|
Seems to be full path to me.
Windows and Linux.
The alternative is a partial path. And it is certainly not that. Not in either OS.
|
|
|
|
|
It's partial path on Windows. The first / assumes "the current drive", whatever that is at the time.
|
|
|
|
|
I'm pretty sure that's a Linux path. On my Ubuntu system, when I use the GUI to mount removable media it's mounted as /media/k5054/Partition, where Partition is the partition label or UUID, etc.
Unless the OP has the same media mounted, the compiler isn't going to find it. But one should use relative paths in general, and use -I flags to tell the compiler/pre-processor where to search. Ditto -L flags to the linker to tell it where to find libraries.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
I should have been more specific. If that path was on Windows, it would have been a partial path.
I understand it's a Linux path.
|
|
|
|
|
Dave Kreskowiak wrote: The first / assumes "the current drive", whatever that is at the time.
Yes I know how pathing works in unix (and linux) and windows.
There are only two terms that I know. So if you know of another please provide the term and definition.
- Partial path.
- Full path.
Are you claiming that the first forward slash on a windows file path only means a 'partial path' but on unix/linux it always means a 'full path'?
On linux/unix the path might have a path that resolves to a different drive.
Otherwise, just like windows, it resolves to the current drive.
Thus it is in deemed a 'full path' on windows and unix/linux.
In terms of this forum which would be relevant for C/C++ include file paths...
A partial path in an include path on both types of OS will use the rules associated with the build process to resolve the path. That can either be because it defined a 'current' directory or it will resolve to the execution directory (or some variant.)
A full path (forward slash) in an include path on both types of OS will end up using the current drive excepting of course unless there is a path resolution to a different drive for linux/unix.
|
|
|
|
|
Quote: just like windows, it resolves to the current drive.
This is what I'm calling a partial path.
I'm not calling out anyone for anything here. I made a mistake because I assumed Windows. My mistake also shows that I don't do Linux very much, like once every couple of years so I have re-learn this crap every time.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
