C / C++ / MFC

Re: SOLVED (?) Re: Linking libraries - follow-up- gcc++ won't link

29-Jan-20 4:00

Post-mortem FYI
SOLVED(?)
1.Both projects ( IDE terminology) works as expected.
NOT REALLY SURE WHY.
2.The “mother” executable - project has -lbluetooth -lRPI_BT_LIB, but ONLY
-L "${workspace_loc:/RPI_BT_LIB/Debug}" optioned.
3. There are NO references / options to “bluetooth” in RPI_BT_LIB, only source includes.
3. Adding “bluetooth” as per this ( no -l or -L !)
other
An object file to be fed straight into linking. Any file name with no recognized suffix is treated this way.
Creates “cannot find ...” error
4. Adding “/usr/…/bluetooth” creates “ did not link ...” error but has no effect on processing.
(It was pointed out that GCC was not optioned to link )
5. running “make clear” idefinites full library file name - “libRPI_RT_LIB.a”
6. Using “standard IDE” ( I am calling IDE UI form "standard" ) to build type .a library gives NO linking options, however building .so gives ALL options.
7. Using “standard IDE form” to build a project – executable or library – creates “system” default includes.
NOT sure if they are used only for source or linking libraries.

As far as I can tell this whole mess was because I could not tell if I was using
wrong GCC options
or
wrong syntax

It was NEVER about (-l / -L ).

The unanswered question remains - how does the RPI_BT_LIB library manages to use "bluetooth" library.

Richard MacCutchan29-Jan-20 4:16

Richard MacCutchan

29-Jan-20 4:16

Vaclav_ wrote:
how does the RPI_BT_LIB library manages to use "bluetooth" library.

The same way that any code uses any library. Define the external references and add the library to the build process. Take a look at gcc library - Google Search[^] for more detailed information.

Reverse engineering GCC output - need library file (name) and path.

Vaclav_27-Jan-20 5:34

Re: Reverse engineering GCC output - need library file (name) and path.

27-Jan-20 5:34

I am posting this here because I hope the actual output will help to solve the issue , and it is not small!
I have an app using bluetooth - linked to library "bluetooth". It works fine.
I need to identify the actual type of library ( Linux .a or .so ).
GCC options do not require prefix, such as "lib." or suffix - .a or .so thus GCC output cannot tell me the library file full name.
I also need the (-L) path to the library and GCC does not correlate -L with -l.

Help will be appreciated.

PS Please ignore the "undefined.." error.

Here is the actual GCC linker output

make all 
Building target: RPI_BT_SERVER
Invoking: GCC C++ Linker
g++ -L/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_COMMON/src/MODULES/M_SOCKET_COMMON -L"/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB/Debug" -v -o "RPI_BT_SERVER"  ./src/MODULES/M_FILE_CLASS/CFILECLASS.o  ./src/RPI_BT_SERVER.o   -lbluetooth -lRPI_BT_LIB
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.12' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12) 
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-L/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_COMMON/src/MODULES/M_SOCKET_COMMON' '-L/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB/Debug' '-v' '-o' 'RPI_BT_SERVER' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/5/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper -plugin-opt=-fresolution=/tmp/ccoEji8m.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro -o RPI_BT_SERVER /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/5/crtbegin.o -L/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_COMMON/src/MODULES/M_SOCKET_COMMON -L/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB/Debug -L/usr/lib/gcc/x86_64-linux-gnu/5 -L/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/5/../../.. ./src/MODULES/M_FILE_CLASS/CFILECLASS.o ./src/RPI_BT_SERVER.o -lbluetooth -lRPI_BT_LIB -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/5/crtend.o /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crtn.o
/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB/Debug/libRPI_BT_LIB.a(CSOCKETCOMMON.o): In function `std::C_SOCKET_COMMON::SelectDevice(int)':
/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB/Debug/../MODULE/M_SOCKET/CSOCKETCOMMON.cpp:144: undefined reference to `str2ba'

Gerry Schmitz27-Jan-20 5:55

Gerry Schmitz

27-Jan-20 5:55

Knowing "why" helps to motivate people; otherwise, it sounds like "make work". Seems like knowing what OS you're running under would be more useful.

It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food

Re: Reverse engineering GCC output - need library file (name) and path.

Vaclav_28-Jan-20 2:44

Re: Reverse engineering GCC output - need library file (name) and path.

28-Jan-20 2:44

OK, isn’t all of that info in posted output ?

Richard MacCutchan27-Jan-20 6:09

Richard MacCutchan

27-Jan-20 6:09

Just check the directory where this library is installed and you will see which type it is.

Re: Reverse engineering GCC output - need library file (name) and path.

k505427-Jan-20 6:24

k5054

27-Jan-20 6:24

try ldd myprog. If the library shows up in the output, then it is dynamically linked, e.g. a .so library. If it doesn't, then its a static library (.a).

Usually the linker (ld, not gcc), will prefer the dynamic library over the static, so the resulting executable will a) use new versions of the library, if it gets updated, and b) (less important these days) have a smaller on-disk footprint. If you are linking to the .so and you want to force the linker to use the static library you can do that with the following options to gcc

-Wl,-Bstatic -lsome_lib -Wl,-Bdynamic

If you don't add the -Wl,-Bdynamic at the end, then libc gets statically linked in, too, which is probably not what you want. Of course you could just pass -static to gcc for the final linking stage, and that will produced a static binary (no shared libs), which should run on most linux boxes of with the same architecture (e.g X86 or ARM). I say most, because if you compiled on say Ubuntu 18.04, and tried to run on something ancient, like maybe RedHat 9 (shrike), you would probably get a execution error.

But it would be helpful to know why you want to know this. Normally, we don't care whether we're linking to a dynamic or static library, just as long as the program works. Your question suggests to me that you're bumping up against an issue and are trying to force the OS into doing what you think it should, rather than working with the OS

Re: Reverse engineering GCC output - need library file (name) and path.

Vaclav_27-Jan-20 7:00

Re: Reverse engineering GCC output - need library file (name) and path.

27-Jan-20 7:00

The library works, was build few years back and I do not remember how I did it.

Reason for all this is that I need to implement same library in another project , therefore I need to identify the type and location. Hence "reverse engineering".

leon de boer27-Jan-20 22:28

leon de boer

27-Jan-20 22:28

pick it in the makefile

ifeq (,$(wildcard somelibpath/sonelibrary.a))
    // The library is .a
endif

ifeq (,$(wildcard somelibpath/sonelibrary.so))
    // The library is .so
endif

You can even pick it out of a list of filenames in the makefile .. that is after all what the makefile is there for

In vino veritas

Re: Reverse engineering GCC output - need library file (name) and path.

Vaclav_28-Jan-20 2:45

28-Jan-20 2:45

THANKS

DPI aware, I am confused

Erich Jarz23-Jan-20 7:25

23-Jan-20 7:25

Hi
I read some articles on how to make a win32 prog DPI aware. I want to make a dialog which has
windows controls, bitmaps and gdiplus objects combined.
I am using VS2019 and started a MFC app from scratch.
What would be the right way to get a DPI aware app, because I set DPI to high in the MFC app setting and used GetDeviceCaps to draw the lines. But when DPI is set to HIGH the lines do not match with the controls anymore. When I switch it off, the graphics look blurry, but are on the right position.
I made some screenshots to show what I mean:

Windows 100%, DPI aware to HIGH

Windows 150%, DPI aware to HIGH

Windows 150%, DPI aware to NO

What would be the right approach, so windows controls and graphics match on all resolutions?

thanks
regards
Erich

Gerry Schmitz23-Jan-20 7:37

Gerry Schmitz

23-Jan-20 7:37

In Windows 10 you make your apps "fluent" and don't worry about that stuff. The user controls text size through "Ease of Access" in the control panel.

Stick to Segoe UI fonts; use the "standard resources" for headings and body; size everything divisible by 4; stick to PNGs, using transparent backgrounds when necessary to reduce size.

It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food

Erich Jarz23-Jan-20 8:27

23-Jan-20 8:27

Hi
Thanks, but that didnt answer my question. How should I draw Gdiplus graphics and controls so that they are always drawn correctly (same position) on all Dpi settings?
The code that I use can be seen in the first screenshot.
Regards
Erich

leon de boer24-Jan-20 7:05

leon de boer

24-Jan-20 7:05

Short answer you scale everything long answer you scale everything

Okay to get scale factor you need the DPI of the screen which you use Win32 API

HDC Dc = GetDC(GetDesktopWindow());       // Get Screen DC
int DpiX = GetDeviceCaps(Dc, LOGPIXELSX); // X DPI for this DC (96 for normal screen)
int DpiY = GetDeviceCaps(Dc, LOGPIXELSY); // Y DPI for this DC (96 for normal screen)
ReleaseDC(GetDesktopWindow(), Dc);	      // Release screen DC finished with it now
if (DpiX != 96 || DpiY != 96)	          // High DPI mode active
{
    /* calculate scale */
    double ScaleX = (double)DpiX/96;
    double ScaleY = (double)DpiY/96; 
}

In vino veritas

Erich Jarz24-Jan-20 7:42

24-Jan-20 7:42

Hi
Thanks for your reply. I already tried to calculate the coord with GetDeviceCaps, but that does not work correctly! When I set 150% font size in windows I get a ratio of 144/96=1.5 as expected, but the controls and the dialog itself do not scale that way!

Here a different example:

I have drawn two red rectangles, one with the size of the dialog and an inner one which is the size of a group box. For the size of the dialog rectangle I use GetClientRect. It works on all font sizes (DPI scalings) correct.
For the inner rectangle inside the group box I tried to recalculate the coords with GetDeviceCaps, but that does not work. If I change scaling in windows the inner rectangle is completely off.
So I tried to figure out the correct coords for the inner rectangle by trial and error. Below are the coords which draw the correct rectangles in relation to the group box.
But how can I calculate them, I get some weird values? In the x axis I would get a factor of 1.3328 and on the y axis a factor of 1.62 with 150% scaling, not 1.5 as expected!?

Screenshot at 100%

// coords at 100%
Dialog rectangle coord = 0/0 - 1445/832
group box rectangle coord = 624/9 - 1247/581

Screenshot at 125%

// coords at 125%
Dialog rectangle coord = 0/0 - 1685/1088
group box rectangle coord = 728/11 - 1456/761

Screenshot at 150%

// coords at 150%
Dialog rectangle coord = 0/0 - 1926/1344
group box rectangle coord = 831/13 - 1664/941

How can I calculate the right coordinates for these elements ?

thanks
regards
Erich

leon de boer24-Jan-20 19:41

leon de boer

24-Jan-20 19:41

You are obviously loading the dialog from a resource file or template.
Those have a normal DPI scale of 48 and yes it gets messy.

1.) Don't do it .... manually create the dialog and insert the items.

or

2.) If you don't want to do it manually on window entries that draw on the WM_CREATE grab the size and scale of the window just like you did. Which is basically what Gerry is saying below and contain your draws to windows. That means if you want to draw something on the dialog background make an transparent invisible window in the resource so it scales with the rest of the dialog and draw on it.

You are sort of creating a mountain out of a molehill.

In vino veritas

modified 25-Jan-20 1:50am.

Erich Jarz26-Jan-20 20:22

26-Jan-20 20:22

Hi
Thanks for your replies. I drew the controls with the MFC resource editor, so the scaling doesnt match as you said.
So, I started a Win32 desktop application from scratch without MFC or other wrappers. I will do all drawings and scalings myself for all elements. I hope this will solve my DPI problems. I know that this is much work, but I only have experience with VisualStudio and MFC and I have to learn the basic WIN32 stuff first. I wanted to know the underlying win32 basics anyway.

Thanks for your help!
regards
Erich

Gerry Schmitz24-Jan-20 8:27

Gerry Schmitz

24-Jan-20 8:27

My "answer" was, why bother when the OS / framework will do it for you.

Besides dimensions, you have to scale positions (top, left), fonts, pixel fiddling.

With a "ViewBox" (as one example) one can do in 1 minute what you'll be spending the next month on.

Your graphics are "Border" elements within a Grid, inside a viewbox, with whatever relative dimensions you want.

It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food

modified 24-Jan-20 14:34pm.