Re: compiling STAR staticaly under Linux

Joerg Schilling wrote:

Francois Vigneron <[email protected]> wrote:

I would like to be able to use STAR in a rescue environment under Linux
with Redhat FC4.
The FC4 Redhat rescue environment doesn't seem to include STAR, although
the main install offers an old version of STAR.
(Some former Redhat rescue environnement did even include a broken
CPIO.... that wasn't able to execute with the dynamic libs!)
In order to avoid problems, I would like to compile a STATIC version of
STAR.

Why?

The time of static compiling did virtually end in 1988.
The fact that static compiling has been kept for special situations
is caused by unclean system setup.......
This time did end 2 years ago, when Solaris 10 demonstrated that 100% dynamic
linking works like a charm.

I have had problems in the past with binaries in Redhat FC1 recue disks
that could not execute due to bad librairies. The binaries were that of
FC1 and the libs were also included on the disk. The only way to escape
that sort of problem is to have static binaries.

I have got static versions of grub, cpio, tar, bzip2, etc... in order to
avoid dynamicaly linked lib problems when libs and distrib changes.

Strange, Solaris uses the dynamic libs - namely libc - to prevent
kernel interface changes to become visible in userprograms. Does Linux use
libc as additional cause of problems?

Yes, but that is field experience over 10 years of using Linux... ;-)

So far, I have been using CPIO for backup and RESTAURE. A backup is
worth nothing if it can not be restaured.

I strongly recommend not to use cpio for backups. Cpio is an outdated
archive format with many limitations. Let me give a hint: if you have
star, there is no need to have cpio also. Star includes full cpio
support.

I know that your tool is much better than CPIO. But STAR is not on
rescue DVDs and CDROMs. So this means additional problems when trying
to restaure data. STAR sould be present in the default install and on
RESCUE disks. We should try persuading Redhat and others of the benefit
of this. I have even seen Redhat distribs with non-fuctionnal CPIO
tools (corrupted binary that did faulty CPIOs!!!).

What I usualy do is write the backup file with CPIO and test afterwards
if it can be read (10% of backups are corrupted before testing). The
main problem is growing files (files that grow while you are doing a
backup). What I do is that I don't backup file that might grow....
(don't laugh!).

I am now trying to use STAR instead (no problem with "growing" files).
In order to prove that I can use STAR for backups, I am trying to
restaure a backup that was done with STAR. If I fail restauring the
system in working order on a new computer then it is no use and I'll
revert to CPIO.

My opinion is that critical Unix commands should be linked "static"
because if you have got a lib problem then you can not restaure your
backups from the rescue DVD. Saving a few megabytes on disk is not very
financialy usefull considering that a small disk is now a 80GByte disk.

I have tried to compile STAR staticaly. But I get mixed up in the
compile environnement. Is there a clean way to do this?
Have I missed something in the manual?

README.compile gives hints and 'ved' comes with a sample static makefile.

smake LDOPTX=-dn should work if you have a working static libc.

Thank you for your help. I'll try recompiling it on another system.
I'll let you know via the list what happens.

Let me warn you: I asume that you will fail on Linux. glibc seems no
longer to be suitable for static linking since about 5 years because
of a rotten gcvt() implementation in glibc.

Ok. At least I know what to hack if the binary does not work.

Thank you.

Jörg