static link libc.a

[toby]

to get glibc to static link i have to use

// glibc static linked  good
{$linklib /lib/libc.a}
function c_write(const fd: cint; const buffer: pchar; const count: cint): cint; cdecl; external name 'write';

but

// glibc static linked  fails
function c_write(const fd: cint; const buffer: pchar; const count: cint): cint; cdecl; external '/lib/libc.a' name 'write';
gives /usr/local/bin/ld: cannot find -l/lib/libc.a


external 'libc'  works to link to dynamic but full path /lib/libc.so also failes

[marcov]

The external clause is to select linker name spaces, if any. Not for file path information.  Both the external clause and linklib might have libc in them, but are not the same.

[toby]

okay that is good for libc (glibc)

now with musl installed in /projects/

// musl static linked // good
//{$linklib /projects/musl/usr.local.musl/lib/libc.a}
//function c_write1(const fd: cint; const buffer: pchar; const count: cint): cint; cdecl; external name 'write';


// musl dynamic linked // /usr/local/bin/ld: cannot find -l/projects/musl/usr.local.musl/lib/libc
// /etc/ld.so.conf  contains /projects/musl/usr.local.musl/lib    and then ldconfig
{$LIBRARYPATH /projects/musl/usr.local.musl/lib}
{$linklib /projects/musl/usr.local.musl/lib/libc.so}
function c_write1(const fd: cint; const buffer: pchar; const count: cint): cint; cdecl; external name 'write';

[marcov]

FPC only sets parameters to the linker, it is the linker that scans the system.

Use  -s to get a ppas.sh with linker parameters, and play/modify with that till it links

[toby]

thanks marcov

i see what -s has

---

something related/unrelated that took me a while to locate the problem
i usually put 'stuff' after the program 'end.' and it has no effect but now with playing with
the linkiib line
{$linklib /projects/musl/usr.local.musl/lib/libc.so}
it has effect on the code if left uncommented after the program end. as thought it was places in the code itself
i am using fpc-3.3.1   is this is a bug somewhere - i think it violates the rules?

[toby]

i went back to simple problem with glibc using -s   but can't see why

{$linklib /lib/libc.a}   is good

{$linklib /lib/libc.so}  fails   ld script to /lib/libc.so.6
{$linklib /lib/libc.so.6}  fails

the -s ppas.sh and link*.res   shows that the linker
is findind /lib/libc.a with the static linklib but
with the dynamic linklib it is looking for /lib/libc (and not libc.so)

[toby]

if i can do it with a static library why the problems with the shared lubrary?

you said fpc hands the name to ld - it looks like fpc is handing the wrong name to ld

[toby]

finally got it working

static and dynamic glibc and static and dynamic musl in one program

using the -s didn't lead to figuring it out - /etc/ld.so.conf was the solution

[Thaddy]

static and dynamic glibc and static and dynamic musl in one program

In one program? That is horrible design and would give you a zero out of 10.

[rvk]

static and dynamic glibc and static and dynamic musl in one program

If you have static, what would be the use of dynamic in the same program?
(or did you mean that you can switch this with a DEFINE ?)

Also.... why did you want to do a static link to libc?
I thought this was discourage (and that you still needed external libs like libc.so.6 and maybe others to be on the system).
So linking statically seems nice and to work on your own system but might fail on others.

https://stackoverflow.com/questions/57476533/why-is-statically-linking-glibc-discouraged

[toby]

thanks for link

rvk said
Also.... why did you want to do a static link to libc?

just a test program and poc - posters in the following topics said it couldn't be done so i did them in one program

https://forum.lazarus.freepascal.org/index.php/topic,64570.0.html"
https://forum.lazarus.freepascal.org/index.php/topic,63680.0.html

rvk said
If you have static, what would be the use of dynamic in the same program?
(or did you mean that you can switch this with a DEFINE ?)

nope no switching
i just got the code i posted in my reply 3 in (originally from Bogen85 in his topic starting post) both in
https://forum.lazarus.freepascal.org/index.php/topic,64570.0.html
working using different fpc function/procedure names and /etc/ld.so.conf entry

turned out to be no big deal looking back but a struggle getting there

point ended up being learned about
{$librarypath vs -Fu on compile line
{$linklib vs external
/etc/ld.so.conf  and  ldconfig -v

i have no intention of linking to glibc ever again or musl for that matter !!!
i once had to use eglibc to compile a problematic qemu a while back though

btw have you ever replaced a glibc rpm or glibc deb with glibc source ... it is a fun project - just have a boot disk handy