GCC build on FreeBSD 7.0 questions

GCC build on FreeBSD 7.0 questions

[Unga]

Hi all

I have successfully (I hope) build GCC 4.3.1 from sources on FreeBSD 7.0 on i386. New compiler's file references are correct but weired. I prefer to fix it and appreciate any help in that regards. Here are more details:

The configuration line used:
../gcc-4.3.1/configure --prefix=/usr --enable-shared --enable-threads=posix \
--enable-languages=c,c++,fortran,objc,obj-c++ \
--libexecdir=/usr/libexec --infodir=/usr/share/info --mandir=/usr/share/man

echo 'main(){}' > dummy.c
cc dummy.c -v -Wl,--verbose &> dummy.log

1) grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log
	/usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crt1.o succeeded
	/usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crti.o succeeded
	/usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crtn.o succeeded

/usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crt1.o is actually /usr/lib/crt1.o, why not refer directly?

How it refer /usr/lib/libc.so is as -lc (/usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../libc.so)!

How to fix this?


2) Some files are installed in /usr/lib/gcc/i386-unknown-freebsd7.0/ and /usr/libexec/gcc/i386-unknown-freebsd7.0/. I prefer files to be installed in /usr/lib/, /usr/libexec/, etc. Eg. crt* files (crtbegin.o, crtend.o, etc) to be installed in just /usr/lib/ . How to get this done?

3) I don't think I need header files in /usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/include and 
/usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/include-fixed. Normally they pollute build environment. Any way to not install them too?

Kind regards
Unga




      

Re: GCC build on FreeBSD 7.0 questions

[Ian Lance Taylor]

Unga <unga888@yahoo.com> writes:

> 1) grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log
> 	/usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crt1.o succeeded
> 	/usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crti.o succeeded
> 	/usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crtn.o succeeded
>
> /usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crt1.o is
> actually /usr/lib/crt1.o, why not refer directly?

It has to do with preserving the ability to move the entire gcc
installation tree to a new location and have it continue to work.

> How it refer /usr/lib/libc.so is as -lc (/usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../libc.so)!

Look at the -L options passed to the linker to see what happens there.

> How to fix this?

It's not a bug.  Don't fix it.


> 2) Some files are installed in /usr/lib/gcc/i386-unknown-freebsd7.0/
> and /usr/libexec/gcc/i386-unknown-freebsd7.0/. I prefer files to be
> installed in /usr/lib/, /usr/libexec/, etc. Eg. crt* files
> (crtbegin.o, crtend.o, etc) to be installed in just /usr/lib/ . How
> to get this done?

You can just move them by hand if you like.  gcc will still be looking
for those directories, though.  Those directories exist so that you
can install multiple versions of gcc for multiple targets on one
machine.


> 3) I don't think I need header files in
> /usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/include and
> /usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/include-fixed. Normally
> they pollute build environment. Any way to not install them too?

Again, you can mix them by hand if you like.  Be sure that there
aren't files with the same name in the two directories, although I
don't think that happens these days.


These issues all arise in order to support complex installation
scenarios.  They aren't useful for simple cases like yours, but on
the other than they also don't hurt.  The best approach is to not let
it bother you.

Ian

Re: GCC build on FreeBSD 7.0 questions

[Unga]

--- On Wed, 7/30/08, Ian Lance Taylor <iant@google.com> wrote:

> From: Ian Lance Taylor <iant@google.com>
> Subject: Re: GCC build on FreeBSD 7.0 questions
> To: unga888@yahoo.com
> Cc: gcc-help@gcc.gnu.org
> Date: Wednesday, July 30, 2008, 10:14 PM
> Unga <unga888@yahoo.com> writes:
> 
> > 1) grep -o '/usr/lib.*/crt[1in].*succeeded'
> dummy.log
> >
> 	/usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crt1.o
> succeeded
> >
> 	/usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crti.o
> succeeded
> >
> 	/usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crtn.o
> succeeded
> >
> >
> /usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crt1.o
> is
> > actually /usr/lib/crt1.o, why not refer directly?
> 
> It has to do with preserving the ability to move the entire
> gcc
> installation tree to a new location and have it continue to
> work.
> 
> > How it refer /usr/lib/libc.so is as -lc
> (/usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../libc.so)!
> 
> Look at the -L options passed to the linker to see what
> happens there.
> 
> > How to fix this?
> 
> It's not a bug.  Don't fix it.
> 
> 
> > 2) Some files are installed in
> /usr/lib/gcc/i386-unknown-freebsd7.0/
> > and /usr/libexec/gcc/i386-unknown-freebsd7.0/. I
> prefer files to be
> > installed in /usr/lib/, /usr/libexec/, etc. Eg. crt*
> files
> > (crtbegin.o, crtend.o, etc) to be installed in just
> /usr/lib/ . How
> > to get this done?
> 
> You can just move them by hand if you like.  gcc will still
> be looking
> for those directories, though.  Those directories exist so
> that you
> can install multiple versions of gcc for multiple targets
> on one
> machine.
> 
> 
> > 3) I don't think I need header files in
> > /usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/include and
> >
> /usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/include-fixed.
> Normally
> > they pollute build environment. Any way to not install
> them too?
> 
> Again, you can mix them by hand if you like.  Be sure that
> there
> aren't files with the same name in the two directories,
> although I
> don't think that happens these days.
> 
> 
> These issues all arise in order to support complex
> installation
> scenarios.  They aren't useful for simple cases like
> yours, but on
> the other than they also don't hurt.  The best approach
> is to not let
> it bother you.
> 
Hi Ian

Thanks for the reply. 

I overlooked the fact multiple GCC installations. As the issues I mentioned makes no harm, I have decided to just leave it like that. I'm not sure  whether it slightly makes it slow to compile and link.

Kind regards
Unga