[fpc-pascal] Can someone please explain the linker to me?

[Ewald]

Once upon a time, Anthony Walter said:
> On 13.04 this broke and I found there was no libssl.so in /usr/lib but
> there was a libssl.so.1.0.0 in /lib/x86_64-linux-gnu/libssl.so.1.0.0.
> I then created a symbolic link to that shared object in my /usr/lib
> folder named libssl.so and everything worked, or so I thought.
>
> When I tried to use the crypto functions again on 13.04 the linker
> said it couldn't link "libcrypto", so it would seem that on one distro
> the crypto function are in libssl while in another they are in
> libcrypto .... okay I guess that happens.
>
> But the the weird thing is I created a symbolic link
> from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> to /usr/lib/libcrypto.so.1.0.0 and when I switch my pascal code to use
> "external 'libcrypto.so.1.0.0'" I still get the linking error stating
> that libcrypto could not be found. I had to create the symbolic link
> as /iusr/lib/libcrypto.so and then it worked.
Perhaps libopenssl references libcrypto, and thus you need both in your
library search path. By the way, why son't you just add your
`/lib/x86_64-linux-gnu/` directory to the library path? I believe there
was an command line option for fpc that did that (or you can maybe pass
a similar option to the linker directly). [not tested: try adding
`-Fl/lib/x86_64-linux-gnu/` to the fpc command line?]

>
> Having a thought I renamed my external to this garbage "external
> 'libcrypto.so.1.2.asdasd'" and it compiled and everything still works.
> So it would seem that the linker is is ignoring everything outside the
> word 'crypto' and requires I specifically name the files
> 'libcrypto.so' and 'libssl.so'.
IIRC the part after `.so` is considered a version number (or indication
thereof). The behaviour you are seeing is *probably* that the linker
could not find `libcrypto.so.1.2.asdasd`, so it decides to use the one
it found instead.

Anyway, I don't know that much about `the linker` either, but this would
be my guess.

-- 
Ewald