[gcc] Build fail for 2.95.3 version on a modern system

[gcc] Build fail for 2.95.3 version on a modern system

[Marcello Stanisci]

Hi,

I am trying to build gcc 2.95.3 with my gcc 4.7 on a debian stable
(wheezy) environment.

Once gcc 4.7 has built xgcc (that is, I guess, the actual gcc 2.95.3),
the compilation process
tries to build something with xgcc and the problem is that xgcc can't
find some header files that
I do have in my system.

How can I tell `make'  to give a certain directory to xgcc where it
can search for header files?

I tried setting CFLAGS='-I /di/rectory/' but that is simply ignored by xgcc.
I also tried changing the variable GCC_FOR_TARGET = $$r/gcc/xgcc
-B$$r/gcc/ -B$(build_tooldir)/bin/ -I$(build_tooldir)/include
adding '-I /di/rectory/' to its string but never happened.


Thanks in Advance to anyone who will reply.

-ms

Re: [gcc] Build fail for 2.95.3 version on a modern system

[Kai Ruottu]

18.2.2014 14:09, Marcello Stanisci kirjoitti:
> Hi,
>
> I am trying to build gcc 2.95.3 with my gcc 4.7 on a debian stable
> (wheezy) environment.
>
> Once gcc 4.7 has built xgcc (that is, I guess, the actual gcc 2.95.3),
> the compilation process
> tries to build something with xgcc and the problem is that xgcc can't
> find some header files that
> I do have in my system.

Where the gcc-2.95.3's cpp0 (or something like that for the C 
PreProcessor)  now searches
the headers?  If not from the default :

   /usr/local/include
   $prefix/lib/gcc-lib/$target/2.95.3/include
   $prefix/$target/include
   /usr/include

(for a native GCC) then where?  Of course everyone who uses GCC is 
expected to know how
to put its components to tell their search paths... If you yet don't 
know, please learn this
thing, for instance via Google like looking via "search paths for GCC"...

> How can I tell `make'  to give a certain directory to xgcc where it
> can search for header files?
>

That isn't sane, much better is to find out why it now searches in wrong 
places and not in
the expected places...  Something wrong in the configure command?

Re: [gcc] Build fail for 2.95.3 version on a modern system

[Marcello Stanisci]

> to put its components to tell their search paths... If you yet don't know,
> please learn this
> thing, for instance via Google like looking via "search paths for GCC"...

I don't need this information, I know where it searches for headers,
and it searches
in wrong places; I just only need to tell to the almost built compiler
to search in an
alternative directory. The point is that I can't use the -I and -L
option on xgcc, beacause
it isn't launched by me; it is launched by its compilation process.

Re: [gcc] Build fail for 2.95.3 version on a modern system

[Florian Weimer]

On 02/18/2014 01:09 PM, Marcello Stanisci wrote:

> I am trying to build gcc 2.95.3 with my gcc 4.7 on a debian stable
> (wheezy) environment.

This will not work due to lack of multi-arch support.  You need to 
inject the missing system include paths, e.g. /usr/include/x86_64-linux-gnu.

It's easier if you do this on a squeeze system (and probably current 
Fedora as well).

-- 
Florian Weimer / Red Hat Product Security Team

Re: [gcc] Build fail for 2.95.3 version on a modern system

[Marcello Stanisci]

2014-02-18 17:19 GMT+01:00 Florian Weimer <fweimer@redhat.com>:
> On 02/18/2014 01:09 PM, Marcello Stanisci wrote:
>
>> I am trying to build gcc 2.95.3 with my gcc 4.7 on a debian stable
>> (wheezy) environment.
>
>
> This will not work due to lack of multi-arch support.  You need to inject
> the missing system include paths, e.g. /usr/include/x86_64-linux-gnu.

I did the injection, it has been possible by appending the string
``-I /usr/include/i386-linux-gnu/'' to both LIBGCC2_INCLUDES and
INCLUDES variables
in file gcc/Makefile.

Unfortunately, there is another issue. The fresh built compiler, when
invoked by `make', calls the linker
(that is the native linker of my system - gnu ld 2.22) and the linker
cannot find crt1.o and crti.o that exist
on my system. I also give the
``-Wl,--library-path=/usr/lib/i386-linux-gnu/'' (that is the directory
where those
object file are) option to the fresh built compiler but it simply ignore it.
Furthermore, I just tried to compile an hello_world program to see if
my linker find crt1.o and crti.o and it goes fine.

I paste below the response of the compilation process:

stage1/xgcc -Wl,--library-path=/usr/lib/i386-linux-gnu/ -Bstage1/ \
-B/usr/local/i686-pc-linux-gnu/bin/  -DIN_GCC \
-O2 -g -O2  -DHAVE_CONFIG_H  \
-o gencheck gencheck.o

/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
collect2: ld returned 1 exit status


So, why does the linker not find a file that I have in my system and
that it normally finds?
And, why does the linker ignore the option passed to it through the string
``-Wl,--library-path=/usr/lib/i386-linux-gnu/'' ?

Thanks!
-ms

Re: [gcc] Build fail for 2.95.3 version on a modern system

[Marcello Stanisci]

Fixed, it seems to be a bug.

Just: export LIBRARY_PATH=/di/rectory
to instruct the linker about where to search for object files.

2014-02-19 23:28 GMT+01:00 Marcello Stanisci <stanisci.m@gmail.com>:
> 2014-02-18 17:19 GMT+01:00 Florian Weimer <fweimer@redhat.com>:
>> On 02/18/2014 01:09 PM, Marcello Stanisci wrote:
>>
>>> I am trying to build gcc 2.95.3 with my gcc 4.7 on a debian stable
>>> (wheezy) environment.
>>
>>
>> This will not work due to lack of multi-arch support.  You need to inject
>> the missing system include paths, e.g. /usr/include/x86_64-linux-gnu.
>
> I did the injection, it has been possible by appending the string
> ``-I /usr/include/i386-linux-gnu/'' to both LIBGCC2_INCLUDES and
> INCLUDES variables
> in file gcc/Makefile.
>
> Unfortunately, there is another issue. The fresh built compiler, when
> invoked by `make', calls the linker
> (that is the native linker of my system - gnu ld 2.22) and the linker
> cannot find crt1.o and crti.o that exist
> on my system. I also give the
> ``-Wl,--library-path=/usr/lib/i386-linux-gnu/'' (that is the directory
> where those
> object file are) option to the fresh built compiler but it simply ignore it.
> Furthermore, I just tried to compile an hello_world program to see if
> my linker find crt1.o and crti.o and it goes fine.
>
> I paste below the response of the compilation process:
>
> stage1/xgcc -Wl,--library-path=/usr/lib/i386-linux-gnu/ -Bstage1/ \
> -B/usr/local/i686-pc-linux-gnu/bin/  -DIN_GCC \
> -O2 -g -O2  -DHAVE_CONFIG_H  \
> -o gencheck gencheck.o
>
> /usr/bin/ld: cannot find crt1.o: No such file or directory
> /usr/bin/ld: cannot find crti.o: No such file or directory
> collect2: ld returned 1 exit status
>
>
> So, why does the linker not find a file that I have in my system and
> that it normally finds?
> And, why does the linker ignore the option passed to it through the string
> ``-Wl,--library-path=/usr/lib/i386-linux-gnu/'' ?
>
> Thanks!
> -ms

Re: [gcc] Build fail for 2.95.3 version on a modern system

[Jonathan Wakely]

On 19 February 2014 23:18, Marcello Stanisci wrote:
> Fixed, it seems to be a bug.

No, it's not a bug that a compiler released more than a decade before
your Debian system doesn't know how your Debian system is arranged.

> Just: export LIBRARY_PATH=/di/rectory

It's more helpful if you provide the real options you're using, not
fake ones like /di/rectory.

Re: [gcc] Build fail for 2.95.3 version on a modern system

[Jonathan Wakely]

On 19 February 2014 22:28, Marcello Stanisci wrote:

> Unfortunately, there is another issue. The fresh built compiler, when
> invoked by `make', calls the linker
> (that is the native linker of my system - gnu ld 2.22) and the linker
> cannot find crt1.o and crti.o that exist
> on my system. I also give the
> ``-Wl,--library-path=/usr/lib/i386-linux-gnu/'' (that is the directory
> where those
> object file are) option to the fresh built compiler but it simply ignore it.

I think you can use LD_LIBRARY_PATH to point the linker at that directory.

> Furthermore, I just tried to compile an hello_world program to see if
> my linker find crt1.o and crti.o and it goes fine.

The linker gets told where to find those files by GCC. Your system GCC
understands the modern layout used by Debian and Ubuntu, the ancient
GCC 2.95 doesn't understand that layout, because it was released many
years before Debian changed its filesystem layout.

> So, why does the linker not find a file that I have in my system and
> that it normally finds?

Because GCC 2.95 doesn't know about the "multiach" filesystem layout
of modern Debian systems.

The env vars shown at
http://gcc.gnu.org/ml/gcc-help/2012-05/msg00083.html solve the problem
for more recent versions of GCC on Debian, they might work for GCC
2.95 too.