Library naming conventions in Linux

[Dinosaur]

Hi All

I have managed to compile both Allegro & CGUI in Linux, but the naming conventions have me stumped.

In CGUI I end up with a library call libcgui_s.a

What should the name be in the .bi file ?
cgui_s
or
lcgui_s
or
libcgui_s

Whatever I change it to, to error is always
ld: cannot find -lcgui

Where does ld get it's library name from ?

Regards

[D.J.Peters]

file: cgui.bi

Code: Select all

#inclib "cgui_s"
...

or

file: cgui.bi

Code: Select all

#ifdef CGUI_STATIC
#inclib "cgui_s" '<-- static lib libcgui_s.a windows and linux
#else
#inclib "cgui" '<-- dynamic lib linux: libcgui.so windows: cgui.dll.a or cgui.dll
#endif
...

[Dinosaur]

Hi All

D.J.Peters, thanks for that.
Am I to assume that because ld is quoting -lcgui as missing, that somewhere
it is set to Dynamic ? , cause if it was set to Static, then it would quote -libcgui_s as missing ? (if indeed it was missing)

dkl wrote in another post.

Another detail is, specifying #inclib "foo" in FB code makes it look for files called libfoo.a or libfoo.dll.a. That means you don't specify the whole file name in the #inclib, but only part of it, otherwise it will fail (#inclib "libfoo.a" would look for a file named liblibfoo.a.a etc.).

Why do I get -lfoo instead of -libfoo as missing?

Regards

[dkl]

cgui.bi from FB 1.03 has

Code: Select all

#inclib "cgui"

so that will look for libcgui.a or libcgui.dll.a.

You can just change it to

Code: Select all

#inclib "cgui_s"

and it should find the libcgui_s.a.

If that's the "official" name for the static version of the CGUI library, then we could also use the solution with #ifdef CGUI_STATIC which DJPeters suggested, so then you could #define CGUI_STATIC and get #inclib "cgui_s" or not do that and get #inclib "cgui".

-l<name> is the gcc command line option for linking with the library of that <name> (e.g. lib<name>.a). The GNU ld linker is mostly aimed at gcc users, that's probably why it reports missing libraries in that format. But even fbc has a similar command line option: -l <name> (with a space behind the -l)

Of course, in gcc's case the -l command line option is your only choice, while with fbc you have either -l or #inclib.

[Dinosaur]

Hi All

Thank you for the replies.
I am still in the deep end.

My main module has the following include line:

#Include once "project.bi"

Project.bi has this:

#define CGUI_STATIC
#define CGUI_STATICLINK

#Include once "allegro.bi"
#Include once "cgui.bi"
#include Once "vbcompat.bi"
#Include Once "file.bi"
#Include once "types.bi"
#Include once "declares.bi"
#Include once "adam.bi"
#Include once "presets.bi"
#Include Once "Win01.bas"
#Include Once "Win02.bas"
#Include Once "WinHelp.bas"
#Include Once "RunMod00.bas"
#Include Once "RunMod01.bas"
#Include Once "RunMod02.bas"

cgui.bi has these lines.

#ifdef CGUI_STATIC
#inclib "cgui_s" '<-- static lib libcgui_s.a windows and linux
#else
#inclib "cgui" '<-- dynamic lib linux: libcgui.so windows: cgui.dll.a or cgui.dll
#endif

but also has this:

xtern "C"
#if defined(CGUI_STATICLINK) or ((not defined(CGUI_STATICLINK)) and (defined(__FB_DOS__) or defined(__FB_LINUX__)))
#define EXTERNVAR extern
#else
#define EXTERNVAR extern import
#endif

Using Geany to compile the program with this statement:

fbc -w all "%f" -target linux -static

The library is in the folder:(it gets put there by the Make Install command)
/usr/local/lib
But I have also copied it to where FB's libraries are.
/usr/local/lib/FreeBasic/linux-x86

Yet still I have the same message:
ld: cannot find -lcgui

EDIT:
Found a second copy of cgui.bi which was not put there by me. But it solved the above problem.
Now I have to figure out why I get thousands of undefined references.
I suspect a similar problem exists with the allegro include files.

Regards

[dkl]

Hmm, maybe it's the -static option.. the problem with that is that it will try to link everything statically, which typically requires some additional system-specific -l options, if the Linux distro in use supports it at all. Perhaps it will work without the -static option (then it can still link with static libs like CGUI, just the system libs won't be linked statically).

[Dinosaur]

Hi All

Thank you dkl, that was spot on.

I changed that when I was troubleshooting.
Now the learning curve starts.
My application compiles without error, but it wont execute, nor can I debug it.
It bombs out as soon as I press Run or debug.

Will persevere, once aggain guys, thanks for the help.

Regards

[Dinosaur]

Hi All

Can someone explain to me how I can get the system to recognise the location of a library.

When I run my application I get the following error:

./WinMain: error while loading shared libraries: liballeg.so.4.4: cannot open shared object file: No such file or directory

When I do a search for that library:

/home/dinosaur/allegro-4.4.2/lib/liballeg.so.4.4
/usr/local/lib/liballeg.so.4.4
/home/dinosaur/allegro-4.4.2/lib/liballeg.so.4.4.2
/usr/local/lib/liballeg.so.4.4.2

However thay are marked as "Link to Unknown" or just "Unknown"

Then I tried to make sense of this article.http://tldp.org/HOWTO/Program-Library-H ... aries.html
and I was more confused. Surely it is not that complex to compile a library and put it someplace where it can be found.

Regards

[caseih]

The linux dynamic loader and linker follows a couple of simple rules if I'm not mistaken. First, If you specified a particular directory when compiling, using the -L flag, the loader will look at that path for the shared library first. Otherwise the loader checks the paths listed in /etc/ld.so.conf and in /etc/ld.so.conf.d/*. If your library cannot be placed in the system paths, then you have to tell the loader where to look. This is done through the LD_LIBRARY_PATH environment variable. So if the library is in the current path, you would run your executable with this command, assuming a bash or similar shell:

Code: Select all

LD_LIBRARY_PATH=`pwd` ./WinMain

Often apps that install to a local, non-standard place put a wrapper script in your path to set this variable automatically. Firefox does this for example.

You can get a report on where the loader is going to look for libraries with a particular binary by running the ldd command. For example:

Code: Select all

$ ldd /bin/ls
	linux-vdso.so.1 (0x00007ffd68f51000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fb02d6c9000)
	libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007fb02d4c0000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb02d117000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fb02cea9000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb02cca5000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fb02d8ee000)
	libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007fb02caa0000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb02c883000)

[caseih]

Forgot to mention that the reason for symlinks in naming libraries is to allow you to compile and link against a library with say a certain major version number, but allow the system to replace the library with newer minor versions without having to recompile or relink the executable. Thus I can link my binary against libgtk-3.so and it will work with any of the GTK3 versions that have the same major version number. This is an arbitrary scheme adopted by all/most linux distributions.

In Windows its customary to ship your binary with a bunch of dlls in the same directory as the binary. In Linux, if you want to do this, you would provide a wrapper starter script that would set up the LD_LIBRARY_PATH directory before running the binary.

Also, there is an environment variable LD_LIBRARY_PRELOAD which lets you override a binary's hard-coded shared library path or the system paths. This is useful for overriding a particular shared library with your own custom one.

[Dinosaur]

Hi All

caseih thank you for your detailed response.

After editing the "/etc/ld.so.conf" the previous error was gone, but I got

(program exited with code: 0)

That made me think to try the CGUI examples, which were compiled at "Make" time and would use the same libraries.
And all of them worked OK.

Some further questions:
Are Static libraries only usable in console mode on Linux or can they be used in any mode ?

When I study the linker line I get a combination of .so and .a libraries.

linking: ld -m elf_i386 -o "WinMain" -dynamic-linker /lib/ld-linux.so.2 "/usr/local/bin/../lib/freebasic/linux-x86/fbextra.x" -L "/usr/local/bin/../lib/freebasic/linux-x86" -L "." -L "/usr/lib/gcc/i686-linux-gnu/4.8" "/usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crt1.o" "/usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crti.o" "/usr/lib/gcc/i686-linux-gnu/4.8/crtbegin.o" "/usr/local/bin/../lib/freebasic/linux-x86/fbrt0.o" "WinMain.o" "-(" -lalleg -lX11 -lXext -lXpm -lXxf86vm -lXcursor -lcgui_s -lfb -ltinfo -lm -ldl -lpthread -lgcc -lgcc_eh -lc "-)" "/usr/lib/gcc/i686-linux-gnu/4.8/crtend.o" "/usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crtn.o"

Is that permitted (to have both Dynamic & Static libraries associated with an executable) ?

EDIT:
When I try to run it in Geany Debug, it quits the debugger & Geany without a message.

Regards

[caseih]

Can't say why you're getting problems but the error code you are getting is usually a runtime error in your program.

You can compile static libraries and link to dynamic libraries in the same executable. So yes, it's permitted.

I should mention, changing /etc/ld.so.conf is usually not recommended. I mentioned it by way of explanation of how the loader mechanism works, not to recommend it. I should have been more clear. The standard way to handle local library paths is to specify the LD_LIBRARY_PATH environment variable. Either manually, or in a wrapper script.

[Dinosaur]

Hi All

caseih, I took the suggestion as intended.
When I resolve all the oddities that you guys are helping me with, I will clear the whole system and
reset to a clean slate. Then start with what I have learned.

You can compile static libraries and link to dynamic libraries in the same executable. So yes, it's permitted.

You have no idea what amount of googling I have done to find an answer to that. Thank you.

I have managed to install and get Insight debugger to work, and it high-lighted what may be the reason for the
program bombing out.

In Windows I have a folder with files that I open with the path:
C:/HMI/Control/Config.jvp

I simply copied the whole folder from Windows to Linux into:
/home/dinosaur

In FreeBasic , if I address that file as:
/home/dinosaur/HMI/Control/Config.jvp
it is not finding it.

Appreciate your time in helping.

Regards

[MrSwiss]

Just a reminder: LIN is case sensitive on everything, WIN is NOT (all converted to lcase() anyway)!

[caseih]

When you say it is not finding it, what do you mean? What runtime error do you get? Can you create a small, compile-able example that reproduces the problem? What error code does open() return? Is the folder you copied readable to your user? In other words is it owned by uid dinosaur and is the user bits set to read on the files themselves and the execute bit is on on the directories? As MrSwiss says, are you sure of the file and path's case?