GCC 3.2.2

torsten torsten at inetw.net
Thu Feb 6 17:32:31 PST 2003


On Thu the 06 Feb 2003 at 18 hours EST
TT wrote...
>torsten wrote:
>
>>libstdc++ is the problem.  Mozilla binary is compiled againt it
>>dynamically,
>>obviously not the version with my compiler.  I just create a symlink,
>>and
>>mozilla seems to be happy.
>>
>>This may be a "purity" issue - having binaries linked to old libraries
>>does
>>not sit well with me.  I think this is what SCO does - sell ancient
>>libraries
>>that people still need to run their ancient (but very
>useful/productive)>programs.
>>
>>  
>>
>I don't know how you install the packages, but most of the errors I
>have seen related to symlink style package mangement is that people
>install the packages incorrectly. Most of the times they install the
>packages with the prefix of the physical location not where it is
>supposed to be symlinked.
>
>For example consider gcc. In symlink style package management, the 
>physical location for gcc will be something like /pkg/gcc/3.2.2/usr but
>
>the location where other packages should look for it is /usr. Most 
>people install gcc with --prefix=/pkg/gcc/3.2.2/usr and then make 
>symlinks in /usr. Now when compiling mozilla, gcc will link mozilla to 
>libstdc++ in /pkg/gcc/3.2.2/usr/lib and not /usr/lib since gcc 'knows' 
>that it was installed in /pkg... The correct way to install would be to
>
>pass --prefix=/usr during compile and then use either the DESTDIR 
>approach if the pkg supports it or to copy the files over manually.
>
>This link has more details on it 
><http://www.gnu.org/software/stow/manual.html#SEC7>.
>
>BTW, if anyone posts a reply, post it to *lfs-support* or lfs-chat.
>

I spent a couple of years --prefix into subdirectories.  This worked
until I moved the subdirectories, and this broke many things.  So,

Your description matches exactly how I do it.  All programs think they
are sitting in the
normal tree.  I only compile with --prefix=/usr or --prefix=/usr/local.
There are two effective ways to compile programs like this, and put them
in their subdirectories.  You mentioned one.

The second method is for programs that don't have DESTDIR, or don't
honor it.  After I install a program, I diff the filesystem to find out
where it put things.  This is not really necessary, but it helps me
catch stray files.  I then cd to the package-sources directory, and do:

epkg -r *

and that will remove every packaged program from my system.  I package
everything, right down to gcc and glibc.  It also rmdir's all
the unused directories.  Now, I have a filesystem which contains only
the contents of one program.  I simply move the filesystem to the
appropriate package subdirectory, then issue

epkg -b

and that will relink everything back in place - it also handles creation
of all necessary directories.  Now I have my filesystem back up, with
the
just-installed program linked in.

This works with LFS, because after removing glibc, I still have the
static
tools to use.  Also, epkg is statically linked, so it always works.

The only ugly part about this is the need to diff the filesystem - it's
not
to bad, but not elegant.  This is the same functionality as the noted 
install-log program, but the website is down.  So I just used find/diff
scripts.  Better solution would be itrace.

itrace watches a program.  With it's combined kernel module, it can
trace
the creation of every file a program makes, dynamic and statically
linked.
checkinstall, installwatch, and friends are not able to watch a
statically-
linked program, so they would not  work for lfs's static "make" and
"configure".  

With itrace, I could automate the packaging part of this.  epkg already
handles linking, is well-supported (authors respond to every email),
has some cool features (installs tar.gz/bz2 packages pulled from gtp,
http).


So, to summarize, I'm thinking about taking over itrace.  Then
installing
an lfs package would amount to:
tar zxvf program.tar.gz
cd program
./configure --prefix=/usr/local
itrace make install

and you magically have a package, which is symlinked into the standard
filetree, and the program believes it is linked into the standard file
tree.

No need for DESTDIR, --prefix, make prefix=, or anything which today
confuses a program.


Ok, so this email was a little more dreaming than practical.  Everything
up to itrace works (epkg, relinking, moving the filesystem tree into a
subdirectory, recreating the tree, etc).  On the itrace website, it says
the kernel modules is "bugged."  It's an Italian ISP, so I imagine he
means "buggy."

Using a watcher like itrace would have the added benefit that the
unlinking/relinking of the filesystem would not be necessary, and this
would save 5-10 seconds or so per install, and take out some of the
manual work.

Torsten



-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-chat' in the subject header of the message



More information about the lfs-chat mailing list