linux static binaries

[Mysoft]

so, i was trying to get freebasic working on the Centos 5.5 that my site hosting provides....

but running fbc gives you

Code: Select all

fbc: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by fbc)

and so... obviously... from yum... i have

Code: Select all

Name       : glibc
Arch       : x86_64
Version    : 2.5

but... so i don't know how to solve that part... (it will require re-cross compiling freebasic?)
but then i have THIS QUESTION...

why there isnt a freebasic version compiled with -static ? to not need such dependencies?

and why that GLIBC.2.14 is used (it's used for memcpy) but any memcpy would do... so, i would like to understand better how that works...

[caseih]

Apparently the FBC binary was built on a glibc 2.15 system, hence it's hard wired to require at least that version because of the binary interface (size of various types, etc).

To get FBC to run on an older OS like that, you'll have to compile it form source, which is a bit tricky since FBC is self-hosted, meaning you need a version of FBC that works already. If you can download a much older version of FBC (pre 1.0) that works on CentOS 5.5, you can use that to build the latest version of the compiler from source. Apparently there is also a way to generate intermediate C code on a different machine and use that to build the compiler using just GCC on your target machine. Sounds a bit complex to me. And note that you'll have to do your building on the CentOS 5.5 target, in order to get the version of glibc you need.

It's a bit analogous to a Windows app requiring a more recent version of MSVCRT.dll than your operating system supports.

[TeeEmCee]

glibc 2.14 was released 2011-06-01. IMO I think 4 1/2 years back-compatibility (when released in early 2016) is much too little; the Windows build probably works on OSes at least 17 years old.

There are good (but not strongly compelling) reasons not to statically link glibc, which I got into in a recent thread on static linking.

Apparently there is also a way to generate intermediate C code on a different machine and use that to build the compiler using just GCC on your target machine.

It's really easy! All you need is gcc and basic libraries like curses!
Just download https://sourceforge.net/projects/fbc/fi ... z/download
Then extract it and run

Code: Select all

make -j4 bootstrap
make install prefix=~/local/fb-1.05

or wherever you want to install it. Or put it in /usr or /usr/local so that you don't even need to update $PATH. Done.
(Note: you have to install it, it won't run properly without because of the path to the 'inc' directory)

It's a bit analogous to a Windows app requiring a more recent version of MSVCRT.dll than your operating system supports.

Mostly. But any Windows program that depends on some certain version of mscvrt.dll (other than the one that's been present on all Windows OSes for 20 years*) but doesn't include it is simply broken. That's quite different to Unix where libc is truly a core part of the OS which evolves.

*there are newer builds of this old version shipped with newer OSes, but they are just minor updates and not comparable to the modern versions of mscvrt_*.dll shipped with Visual Studio.

[Mysoft]

glibc 2.14 was released 2011-06-01. IMO I think 4 1/2 years back-compatibility (when released in early 2016) is much too little; the Windows build probably works on OSes at least 17 years old.

actually freebasic 0.24 is the last one that works on windows 98... (but then again... indeed 2k/XP are 17yo xD) but it's just because GNU tools stopped working on win98, so using freebasic 0.24 ld/as with freebasic 1.0.5 still works

anyway my case is... i want to have a process on my hosting site... it has an updated kernel..."grsec" ... but the libc is 2.5 , and i don't have root... so i will probabily now try to compile a freebasic 0.24 or 1.0 .... in standalone+static mode... to leverage such requirements...

so that i can compile/update binaries right there instead of cross compile... and when compiling i pass -R ./ (to LD) or something, so that dependencies can reside on the same folder as the binary.... using the same simple model of portability as i have on windows...

[srvaldez]

I did the standalone compile on the Mac in order to have multiple versions, I had to make symlinks to usr/local bin and lib folders, don't know if there a better way to deal with that.

[TeeEmCee]

Don't use standalone builds on Unix! I don't know of any reason to use them, they just cause pain. (Well, maybe if your distro doesn't even have a C compiler or other build tools, and you want to install them with fbc instead of installing them system-wide?) AFAIK standalone builds are only intended to be used on Windows.

I did the standalone compile on the Mac in order to have multiple versions, I had to make symlinks to usr/local bin and lib folders, don't know if there a better way to deal with that.

Again, I have no idea why you would want to do that. You can simply install multiple versions of FB into different folders (like the "make prefix=~/local/fbc-1.05" example I gave) instead of installing them system-wide. The only reason you had to symlink anything is because you used a standalone build when you shouldn't.