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

Michalis Kamburelis michalis at camelot.homedns.org
Wed Jan 5 16:49:05 CET 2005


This problem arised with recent change to JEDI-SDL, but it seems a 
general problem with linking to libraries under UNIXes.

Before the change, JEDI-SDL headers linked to libraries named like 
'libSDL.so', using constructs that looked like (after removing preproc 
$ifdefs and resolving constants)

   procedure SDL_Quit; cdecl; external 'libSDL.so';

and it worked OK. Of course, libSDL.so was on all systems only a symlink 
to an actual so file, e.g. to 'libSDL-1.2.so.0.7.0' on my system.

However, recently we're trying to link to 'libSDL-1.2.so.0', to make 
sure that at compilation time we're linking to proper SDL version (since 
JEDI-SDL headers were always supposed to work only with "rather new" SDL 
version, not with "every possible SDL version". As is the case with most 
header units.) But the problem is that doing

   procedure SDL_Quit; cdecl; external 'libSDL-1.2.so.0';

fails at linking with

   /usr/bin/ld: cannot find -lSDL-1.2
   link_so_filename.dpr(4,1) Error: Error while linking

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 ?


More information about the fpc-pascal mailing list