HI,

i'm compiling gcc 4.5.2 and then packaging it using rpm.

many packages automatically assume the path specified by --prefix= to be the final path of course this is wrong because , at first it will go into BUILDROOT then it will be packaged then relocated ....etc (i'm assuming you're familiar with the procedure)

the problem is , when i compile gcc it produces working binaries however the default search path (i.e gcc --print-search-dirs) is messed up (due to the issue described above)

so far i've searched everything and tried all possible things that i could think of but to no avail.

how can i set configure to install the software into $RPM_BUILD_ROOT/usr will forcing the autoconf scripts to hardwire a different path (i.e /usr/) ??

NOTE: please don't refer me to LFS or something similar because 1) i'm already familiar with LFS 2) this isn't about building a toolchain (i've built it already) but rather about how to package and relocate it properly without breaking it !

cheers

The usual thing is:
Build with sane options. When you're installing, use a line like

make DESTDIR=/my/package/dir install.If you build a gcc package for one dir, I don't think you will successfully locate it elsewhere without real effort. Better build 2 packages for that. I would also not use gcc through rpm.You only stand to lose your choice of options..

1 members found this post helpful.

hi , thanks for coming by

i've tried DESTDIR right away after my last post , which successfully placed the gcc files into the desired dir and therefore removed BUILDROOT from the search-paths , however i'm still facing problems .....

what do you mean that i lose my choices with rpm and gcc ? how exactly am i supposed to package it then?
also please elaborate on "building 2 packages" as you mentioned it in your post.

actually i'm intending to build gcc to be used inside a chroot environment in order to do a second build (along with some other tools)

so when i run "gcc --print-search-dirs" (inside the chroot)
i get the following output
why the hell are those paths relative ???
this is insane ! how hard is to fix the "install" path for instance to the same path provided to "prefix" during the build which is "/usr" ??

EDIT:
outside the chroot i get this crap
cheers

You have an absolute path there you know.

/linux/test/usr/bin/../lib64/gcc/x86_64-niteco-linux/4.5.2/ =
/linux/test/usr/lib64/gcc/x86_64-niteco-linux/4.5.2/

The trouble with gcc is that it spreads directories like confetti at a wedding for reasons I never understood. I imagine the ones in chroot should be similar(/usr/bin/back-out-of-bin/lib64<blah>), but not all bits might be in the same place in chroot?

When I was doing LFS, they had a separate install of gcc-2.95.3 on /opt. You must feed it
./configure --prefix=/opt/gcc-2.95.3 --with-bindir=/opt/gcc-2.95.3 etc. and even tell it that the jacks in /opt/gcc-2.95.3 :-P. If you configure for /usr, and install in /opt, you will have a non functional gcc, and some of that stuff is hard coded in. There is no user config file.

If you want a handy package system, check out slackware which uses a few scripts with no real dependency tracking. LFS also have some thing which you put between the make and install on the command line. RPM is headaches. RPM lacks a --middle-finger option which it sorely needs.

1 members found this post helpful.

A "one folder gcc" like the /opt/gcc-2.95.3/ mentioned by business_kid,
can to some extend work when moved to another folder.
(And is very easy to tar, bzip2 to a package that can be unpacked anywhere :
gcc452-x86_64.tar.bz2 , where the parent folder is gcc452/ ).
Must be created by the LFS method
http://www.linuxquestions.org/questi...-1-a-842567/#2
( Configured like ../gcc-4.5.2/configure --prefix=/opt/gcc452/ , etc.)

( "--prefix=/usr/" is worst choice. May also overwrite some files
from the system compiler.)

But why not always use the same folder for your chroot environment,
and simply do '../gcc-4.5.2/configure --prefix=/linux/test/ etc.',
or ../gcc-4.5.2/configure --prefix=/linux/test/gcc452/ etc.,
then all issues are avoided.
( The binaries gcc, g++ can be symlinked to your prefered bin/ directory.)

..

THIS IS GONNA BE A LOOOOOOOOOOOONG POST , bear with me

This is ONLY the case on a normal unchrooted shell

well the confetti install is mostly due the FHS standard as far as i understand it , but to be honest that's not the problem and i don't care where the package throws it's stuff because rpm does an excellent job managing all the spread confetti giving that i can specify the sub root dir with --prefix or similar ...etc

No , in the chroot i'm getting (../lib64/gcc<blah>) and it causes problems with finding compiler binaries ...etc

yes i dealt with the hardcoded stuff by using but i'm still dealing with the dynamic (and weird behavior) of generating relative paths that lead to broken libs and exec bins...etc

No Thanks , i do really appreciate a full blown package manager as opposed to the slack style ( yes for me dependency tracking is a prerequisite) and btw just wanted to point out that the "thing" you described that can be put between make and install is a utility which "redirects" all file operations to a given directory but according to LFS 6.8 it does have caveats and isn't reliable (from what i've gathered) so i'm not using it , besides most if not all packages that hardwire paths have extra features in "make install" that can redirect the installation out of the box without the need for unreliable third party stuff , and those who don't can be solved with running sed over their scripts (incase they aren't binaries)

well despite that fact that i'm not considering dumping RPM , i'm all ears to know about the "--middle-finger" option!
what's that ?
please elaborate...

because things are lil' more complicated , the chroot environment is just a means to an end and not the end itself!
the target is to build a fully chrootable and self-contained toolchain to use for building an entire distro from scratch(scratch as from ziltch , this is not an LFS reference).
the second reason is that the method has to be packaging friendly as opposed to the spaghetti way of lfs , slack or else.

that said , i've made some progress here in the meantime and i'd like to share some results:

i've found out that if you run the following on your distro
and assuming that "/chrootable/shell" contains a fully working GNU toolchain then attempting to compile with gcc with give you the exact same trouble that i'm getting !! (i.e cc1 not found)

and even more interestingly "gcc --print-search-dirs" will produce relative paths as opposed to absolute ones outside the chroot!

the conclusion , is that all distros (at least the once i've examined opensuse 11.2 and CentOS ) are facing the same problem with gcc search-dirs , i've also find out that different distros deal with the problem by installing additional third-party scripts or executables that sort of "search" on behalf of gcc for it's own compiler binaries

for instance in CentOS , an application that i couldn't isolate so far located in /sbin (/sbin is the $PATH variable) is responsible for doing the job (i.e removing/adding /sbin to $PATH will either break or fix gcc)

on opensuse , a package called "openmpi" acts as a proxy for any gcc installation.

the first question is , why not just appending the compiler binaries path directly to $PATH?
to which the answer is : to allow multiple gcc's or even several gcc installations of the same version all of which have the same "--prefix" value , this way every gcc binary would have prior and independent knowledge of it's compiler binaries (cc1 , cc1plus ..) therefore avoiding collision of several gcc's .

the second (and open) question, what's the ideal way to solve this ?
in other words , what tools should we use to point gcc to it's compiler bins?

kind regards

Just a postscript to all of this:

try gcc -print-file specs

and it prints a file called specs buried in the depths of some tree where nobody would expect it. Have you tried hacking that??

well just as a note , i've solved this problem since my last post , forgot to mark the thread as solved , my bad

It would be good to post HOW you solved the problem as people search these forums. Let others benefit from your experience

1 members found this post helpful.

I had the same problem... solution was to do 'export PATH' in bash; that made gcc paths become absolute instead of relative. Does anyone know why gcc's built-in paths would depend on the PATH environment variable?

oops! Ignore this.