|
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.
|
|
|
|
|
Dave Kreskowiak wrote: 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
Ditto, but in reverse!
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Dave Kreskowiak wrote: This is what I'm calling a partial path.
Just to be clear what exactly do you think that the following does on Windows? On Linux?
Specifically is there any realistic difference between the two in general?
#include "/work/x/y/TestClass.h"
|
|
|
|
|
Just to be clear, I'm done with this.
|
|
|
|
|
For unix-like systems there are two terms in general use:
absolute path: any path that starts with a /
relative path: a path relative to the current directory. This is any path that does not start with a / Some examples might be src/projects/foo/bar.c or ../include or ./program
jschell wrote: On linux/unix the path might have a path that resolves to a different drive
Technically true. For example, you might have /home mounted as a separate drive - it might even be a network drive. For the average user, the file system is homogeneous, that is you can navigate to any point in the file tree with out having to know if it's on a separate drive/partition,networked-fs, etc. Its only really an issue for applications that may want to move files from one location to another, as you can not use link() and unlink() to move a file to a different place in the file tree if the source and target are in different file systems.
Edit: It should be noted that file systems may be mounted at any level, so you might have a partition mounted as /home, and another partition mounted as /home/games, and yet another mounted as /home/games/adventure.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
k5054 wrote: Technically true.
You know that on Windows I can map a different drive to a directory in the current drive file system right?
|
|
|
|
|
I would assume that you didn't write that line. The source that gave you that line should have provided instructions about additional packages needed to compile the code: where to get them from, where to place them, etc.
That being said, to me it's quite obvious the author didn't know what he/she was doing. I'd rather look for better quality code.
Mircea
|
|
|
|
|
Salvatore Terress wrote: and the error ( file not found ) is not helping much to fix it.
Well that is easy to correct. Work your way down that path starting in directory /media, to see whether all the subdirectories exist. And oncel you reach the last one, see if the file is there, or if it is possibly mis-spelled. The problem for us with such issues is that we have no access to your system so cannot do any of the searching.
But it is usually not best practice to use full paths in your #include statements. Just us the name of the header file and add its path to the list of directories in the include list - either by use of the -I option to the compiler, or the relevant environment variable (see man page for details).
|
|
|
|
|
[edit] I solved the background flickering problem by changing the last argument in the InvalidateRect() function to false. I also got the test rectangle moving. The only problem left is that the white moving rectangle is still flickering.
[/edit]
I wrote some code, for some reason the rectangle that should work as background is flickering and I can`t get a test rectangle to move.
I`m pasting the source bellow, please help me get my code in proper configuration.
while (WM_QUIT != msg.message)
{
if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
{
UpdateGame();
}
}
switch (msg)
{
case WM_PAINT:
hdc = BeginPaint(hwnd, &ps);
draw(hdc);
movingR = movingR + 0.1;
RECT ARectangle;
ARectangle.left = 0;
ARectangle.top = 0;
ARectangle.right = 600;
ARectangle.bottom = 600;
InvalidateRect(hwnd, &ARectangle, false);
UpdateWindow(hwnd);
EndPaint(hwnd, &ps);
return 0;
void draw(HDC hdc)
{
Gdiplus::Graphics gf(hdc);
Gdiplus::Pen pen(Gdiplus::Color(255, 255, 0, 0));
Gdiplus::SolidBrush brush(Gdiplus::Color(255, 0, 255, 0));
Gdiplus::SolidBrush brush2(Gdiplus::Color(255, 255, 255, 255));
gf.FillRectangle(&brush, 0, 0, 600, 600);
gf.FillRectangle(&brush2,(int)movingR, 200, 100, 100);
}
void UpdateGame()
{
}
modified 10-Dec-23 7:50am.
|
|
|
|
|
You should use double buffering. Just google for “OpenGL double buffering”.
Mircea
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
