public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* [gcc] Build fail for 2.95.3 version on a modern system
@ 2014-02-18 12:09 Marcello Stanisci
  2014-02-18 14:02 ` Kai Ruottu
  2014-02-18 16:19 ` Florian Weimer
  0 siblings, 2 replies; 8+ messages in thread
From: Marcello Stanisci @ 2014-02-18 12:09 UTC (permalink / raw)
  To: gcc-help

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gcc] Build fail for 2.95.3 version on a modern system
  2014-02-18 12:09 [gcc] Build fail for 2.95.3 version on a modern system Marcello Stanisci
@ 2014-02-18 14:02 ` Kai Ruottu
  2014-02-18 19:19   ` Marcello Stanisci
  2014-02-18 16:19 ` Florian Weimer
  1 sibling, 1 reply; 8+ messages in thread
From: Kai Ruottu @ 2014-02-18 14:02 UTC (permalink / raw)
  To: gcc-help

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?

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gcc] Build fail for 2.95.3 version on a modern system
  2014-02-18 12:09 [gcc] Build fail for 2.95.3 version on a modern system Marcello Stanisci
  2014-02-18 14:02 ` Kai Ruottu
@ 2014-02-18 16:19 ` Florian Weimer
  2014-02-19 22:28   ` Marcello Stanisci
  1 sibling, 1 reply; 8+ messages in thread
From: Florian Weimer @ 2014-02-18 16:19 UTC (permalink / raw)
  To: Marcello Stanisci, gcc-help

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gcc] Build fail for 2.95.3 version on a modern system
  2014-02-18 14:02 ` Kai Ruottu
@ 2014-02-18 19:19   ` Marcello Stanisci
  0 siblings, 0 replies; 8+ messages in thread
From: Marcello Stanisci @ 2014-02-18 19:19 UTC (permalink / raw)
  To: Kai Ruottu; +Cc: gcc-help

> 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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gcc] Build fail for 2.95.3 version on a modern system
  2014-02-18 16:19 ` Florian Weimer
@ 2014-02-19 22:28   ` Marcello Stanisci
  2014-02-19 23:18     ` Marcello Stanisci
  2014-02-20  0:02     ` Jonathan Wakely
  0 siblings, 2 replies; 8+ messages in thread
From: Marcello Stanisci @ 2014-02-19 22:28 UTC (permalink / raw)
  To: Florian Weimer; +Cc: gcc-help

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gcc] Build fail for 2.95.3 version on a modern system
  2014-02-19 22:28   ` Marcello Stanisci
@ 2014-02-19 23:18     ` Marcello Stanisci
  2014-02-20  0:03       ` Jonathan Wakely
  2014-02-20  0:02     ` Jonathan Wakely
  1 sibling, 1 reply; 8+ messages in thread
From: Marcello Stanisci @ 2014-02-19 23:18 UTC (permalink / raw)
  To: gcc-help

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gcc] Build fail for 2.95.3 version on a modern system
  2014-02-19 22:28   ` Marcello Stanisci
  2014-02-19 23:18     ` Marcello Stanisci
@ 2014-02-20  0:02     ` Jonathan Wakely
  1 sibling, 0 replies; 8+ messages in thread
From: Jonathan Wakely @ 2014-02-20  0:02 UTC (permalink / raw)
  To: Marcello Stanisci; +Cc: Florian Weimer, gcc-help

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gcc] Build fail for 2.95.3 version on a modern system
  2014-02-19 23:18     ` Marcello Stanisci
@ 2014-02-20  0:03       ` Jonathan Wakely
  0 siblings, 0 replies; 8+ messages in thread
From: Jonathan Wakely @ 2014-02-20  0:03 UTC (permalink / raw)
  To: Marcello Stanisci; +Cc: gcc-help

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2014-02-20  0:03 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-18 12:09 [gcc] Build fail for 2.95.3 version on a modern system Marcello Stanisci
2014-02-18 14:02 ` Kai Ruottu
2014-02-18 19:19   ` Marcello Stanisci
2014-02-18 16:19 ` Florian Weimer
2014-02-19 22:28   ` Marcello Stanisci
2014-02-19 23:18     ` Marcello Stanisci
2014-02-20  0:03       ` Jonathan Wakely
2014-02-20  0:02     ` Jonathan Wakely

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).