[fpc-pascal] Is it possible to link to SO libraries that have filename ending like '.so.0'

[Michalis Kamburelis]

Pedro Lopez-Cabanillas wrote:
> Hi, 
> 
> On Wednesday 05 January 2005 16:49, Michalis Kamburelis wrote:
> 
>>So it seems that fpc passes to ld -lSDL-1.2, and ld looks for
>>'libSDL-1.2.so' (without '.0' suffix). Honestly, I don't know what one
>>should pass to ld to tell it to link to 'libSDL-1.2.so.0'.
>>
>>Question: Can this be somehow fixed in FPC ? Or is it just impossible
>>for FPC to say such thing to ld (so we have another problem that can't
>>be solved because FPC uses external linker) ?
>>
>>In another words, should this be considered something that must be fixed
>>in JEDI-SDL (by changing lib name back to 'libSDL.so') or can this be
>>fixed in newer FPC versions ? Or maybe it's all already working, but I
>>have to pass some command-line parameter to FPC or use some {$...}
>>preprocessor directive to make it work ?
> 
> 
> IMHO, FPC behaves right and matches with other UNIX's compilers, like GCC. In 
> fact it is the "ld" linker behavior, not the compiler.
> 
> You should tell to the linker to bind your program against a generic library 
> 'libSDL.so', and then it will find the real "soname", that will be extracted 
> from the real library and stored into your program, so the dynamic loader 
> (ld-loader) will be able to find the right library at run time. I mean:
> 
> You can have two versions of some library in your system, say:
> /usr/lib/libFOO.so.1.0.0 and /usr/lib/libFOO.so.2.0.0; but only one symlink 
> /usr/lib/libFOO.so pointing to any of them. You only need this symlink to 
> compile programs, not to execute them. This means that even if you have 
> several versions, you only develop programs for one version at a time. The 
> liker extracts from the real library file the "soname" symbol, that is 
> usually something like "libFOO.so.2", including the major version name. This 
> symbol is included in your program, and will be used to find the real library 
> that should be loaded at runtime. You can test the sonames for a program with 
> the "ldd" utility.
> 
> Compare with GCC:
> http://ww.telent.net/linux/GCC-HOWTO-6.html#index.73
> 
> Regards,
> Pedro
> 

Thanks for answer, although I knew that ld does such thing, and I know 
that it's standard UNIX behaviour of linking under UNIXes. But I think 
that in some cases such behaviour is not perfect, as you can't precisely 
specify in source code of your program to what version of the library 
you want to link.

Two examples:
- Consider for example JEDI-SDL sources: you have 'libSDL.so' written in 
source code but compiled executable is actually linked to something more 
specific. Everything seems fine (as I have what I wanted, compiled 
binary is actually linked to 'libSDL-1.2.so.0'). But the problem is that 
it means that the same source code compiled on different systems may 
produce different executable code.

- Example from my own programs: I use libpng. And I use only a limited 
subset of libpng API, and this subset is supported by both libpng.so.2 
and libpng.so.3. So I thought that I'll be OK if I will link to 
'libpng.so', and check at runtime using png_access_version_number 
whether I work with supported version of libpng.

However, this failed as my compiled program was actually linked to 
'libpng.so.3', not 'libpng.so' (because at the time of compilation 
libpng.so was on my system a symlink to libpng.so.3).

Of course, simple workaround exists: don't link using "external" clauses 
but instead do explicit dlopen/dlsym/dlclose calls. But this complicates 
code (a little).

Anyway, I understand that this issue is not related to FPC but to UNIX 
linker behaviour. Thanks for all answers.

-- 
Michalis