Problem building gcc

Problem building gcc

[gideon425.gb5]

I am having problems building gcc 4.6.2

I am using Ubuntu 11.10

Here is the error

/usr/bin/ld: cannot find crti.o: No such file or directory
collect2: ld returned 1 exit status
make[3]: *** [libgcc_s.so] Error 1

To get the error, I just did

../gcc-4.6.2/configure
make

The configure succeeded


The configuration is x86_64-unknown-linux-gnu

The gcc-4.6.2 directory was unwrapped from a standard gcc-4.6.2.tar

What additional information can I supply to help understand this problem?

----------
This message was sent from a MailNull anti-spam account.  You can get
your free account and take control over your email by visiting the
following URL.

   http://mailnull.com/

Re: Problem building gcc

[Marc Glisse]

On Tue, 29 Nov 2011, gideon425.gb5@mailnull.com wrote:

> I am having problems building gcc 4.6.2
>
> I am using Ubuntu 11.10
>
> Here is the error
>
> /usr/bin/ld: cannot find crti.o: No such file or directory

Here is the solution:
export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu

> What additional information can I supply to help understand this problem?

Problem understood, gcc doesn't currently support debian and the 
derivative distributions like ubuntu.

-- 
Marc Glisse

Re: Problem building gcc

[Abdul Wahid Memon]

Hello everyone

I also got the same error and according to your solution I set
LIBRARY_PATH=/usr/lib/x86_64-linux-gnu but then the compilation
process complains that

checking LIBRARY_PATH variable... contains current directory
configure: error:
*** LIBRARY_PATH shouldn't contain the current directory when
*** building gcc. Please change the environment variable
*** and run configure again.
make[2]: *** [configure-stage2-gcc] Error 1
make[2]: Leaving directory `/home/abdul/cc02/gcc-4.6.2/src-infra/obj-gcc'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/abdul/cc02/gcc-4.6.2/src-infra/obj-gcc'
make: *** [all] Error 2

Regards

Abdul
On Wed, Nov 30, 2011 at 12:56 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Tue, 29 Nov 2011, gideon425.gb5@mailnull.com wrote:
>
>> I am having problems building gcc 4.6.2
>>
>> I am using Ubuntu 11.10
>>
>> Here is the error
>>
>> /usr/bin/ld: cannot find crti.o: No such file or directory
>
>
> Here is the solution:
> export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu
>
>
>> What additional information can I supply to help understand this problem?
>
>
> Problem understood, gcc doesn't currently support debian and the derivative
> distributions like ubuntu.
>
> --
> Marc Glisse

Re: Problem building gcc

[Ian Lance Taylor]

Abdul Wahid Memon <engrwahidmemon@gmail.com> writes:

> I also got the same error and according to your solution I set
> LIBRARY_PATH=/usr/lib/x86_64-linux-gnu but then the compilation
> process complains that
>
> checking LIBRARY_PATH variable... contains current directory
> configure: error:
> *** LIBRARY_PATH shouldn't contain the current directory when
> *** building gcc. Please change the environment variable
> *** and run configure again.
> make[2]: *** [configure-stage2-gcc] Error 1
> make[2]: Leaving directory `/home/abdul/cc02/gcc-4.6.2/src-infra/obj-gcc'
> make[1]: *** [stage2-bubble] Error 2
> make[1]: Leaving directory `/home/abdul/cc02/gcc-4.6.2/src-infra/obj-gcc'
> make: *** [all] Error 2

What is the exact value you are using for LIBRARY_PATH?  That is, what
do you see if you run "echo $LIBRARY_PATH"?

Ian

> On Wed, Nov 30, 2011 at 12:56 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
>> On Tue, 29 Nov 2011, gideon425.gb5@mailnull.com wrote:
>>
>>> I am having problems building gcc 4.6.2
>>>
>>> I am using Ubuntu 11.10
>>>
>>> Here is the error
>>>
>>> /usr/bin/ld: cannot find crti.o: No such file or directory
>>
>>
>> Here is the solution:
>> export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu
>>
>>
>>> What additional information can I supply to help understand this problem?
>>
>>
>> Problem understood, gcc doesn't currently support debian and the derivative
>> distributions like ubuntu.
>>
>> --
>> Marc Glisse

Re: Problem building gcc

[Abdul Wahid Memon]

The exact output of echo $LIBRARY_PATH Is /usr/lib/x86_64-linux-gnu

Regards

On Mon, Dec 19, 2011 at 10:20 PM, Ian Lance Taylor <iant@google.com> wrote:
> Abdul Wahid Memon <engrwahidmemon@gmail.com> writes:
>
>> I also got the same error and according to your solution I set
>> LIBRARY_PATH=/usr/lib/x86_64-linux-gnu but then the compilation
>> process complains that
>>
>> checking LIBRARY_PATH variable... contains current directory
>> configure: error:
>> *** LIBRARY_PATH shouldn't contain the current directory when
>> *** building gcc. Please change the environment variable
>> *** and run configure again.
>> make[2]: *** [configure-stage2-gcc] Error 1
>> make[2]: Leaving directory `/home/abdul/cc02/gcc-4.6.2/src-infra/obj-gcc'
>> make[1]: *** [stage2-bubble] Error 2
>> make[1]: Leaving directory `/home/abdul/cc02/gcc-4.6.2/src-infra/obj-gcc'
>> make: *** [all] Error 2
>
> What is the exact value you are using for LIBRARY_PATH?  That is, what
> do you see if you run "echo $LIBRARY_PATH"?
>
> Ian
>
>> On Wed, Nov 30, 2011 at 12:56 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
>>> On Tue, 29 Nov 2011, gideon425.gb5@mailnull.com wrote:
>>>
>>>> I am having problems building gcc 4.6.2
>>>>
>>>> I am using Ubuntu 11.10
>>>>
>>>> Here is the error
>>>>
>>>> /usr/bin/ld: cannot find crti.o: No such file or directory
>>>
>>>
>>> Here is the solution:
>>> export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu
>>>
>>>
>>>> What additional information can I supply to help understand this problem?
>>>
>>>
>>> Problem understood, gcc doesn't currently support debian and the derivative
>>> distributions like ubuntu.
>>>
>>> --
>>> Marc Glisse

Re: Problem building gcc

[Ian Lance Taylor]

Abdul Wahid Memon <engrwahidmemon@gmail.com> writes:

> The exact output of echo $LIBRARY_PATH Is /usr/lib/x86_64-linux-gnu

Looking at the configure script, I don't see any way you could get that
error without having a ':' or ';' in the value of LIBRARY_PATH.

Ian


> On Mon, Dec 19, 2011 at 10:20 PM, Ian Lance Taylor <iant@google.com> wrote:
>> Abdul Wahid Memon <engrwahidmemon@gmail.com> writes:
>>
>>> I also got the same error and according to your solution I set
>>> LIBRARY_PATH=/usr/lib/x86_64-linux-gnu but then the compilation
>>> process complains that
>>>
>>> checking LIBRARY_PATH variable... contains current directory
>>> configure: error:
>>> *** LIBRARY_PATH shouldn't contain the current directory when
>>> *** building gcc. Please change the environment variable
>>> *** and run configure again.
>>> make[2]: *** [configure-stage2-gcc] Error 1
>>> make[2]: Leaving directory `/home/abdul/cc02/gcc-4.6.2/src-infra/obj-gcc'
>>> make[1]: *** [stage2-bubble] Error 2
>>> make[1]: Leaving directory `/home/abdul/cc02/gcc-4.6.2/src-infra/obj-gcc'
>>> make: *** [all] Error 2
>>
>> What is the exact value you are using for LIBRARY_PATH?  That is, what
>> do you see if you run "echo $LIBRARY_PATH"?
>>
>> Ian
>>
>>> On Wed, Nov 30, 2011 at 12:56 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
>>>> On Tue, 29 Nov 2011, gideon425.gb5@mailnull.com wrote:
>>>>
>>>>> I am having problems building gcc 4.6.2
>>>>>
>>>>> I am using Ubuntu 11.10
>>>>>
>>>>> Here is the error
>>>>>
>>>>> /usr/bin/ld: cannot find crti.o: No such file or directory
>>>>
>>>>
>>>> Here is the solution:
>>>> export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu
>>>>
>>>>
>>>>> What additional information can I supply to help understand this problem?
>>>>
>>>>
>>>> Problem understood, gcc doesn't currently support debian and the derivative
>>>> distributions like ubuntu.
>>>>
>>>> --
>>>> Marc Glisse

RE: Problem building gcc

[Pavel Pavlov]

> From: Ralf Wildenhues
> Sent: Friday, May 07, 2010 3:03 PM
> To: Pavel Pavlov
> Cc: gcc-help@gcc.gnu.org
> Subject: Re: Problem building gcc
> 
> Hello Pavel,
> 
> * Pavel Pavlov wrote on Thu, May 06, 2010 at 07:39:54AM CEST:
> > My problem is identical to this one:
> > http://gcc.gnu.org/ml/gcc-help/2008-03/msg00044.html
> > It fails on configure step of binutils in libiberty. I have no idea
> > what's the problem: everything is good, I have all the headers
> > installed and I use gcc-4.4.0 as toolset to build crosscompiler.
> >
> > In that particular case I have this config.status :
> > http://pastebin.com/PSsaya6F
> > Yet, the final config.h is absolutely identical to config.in:
> > http://pastebin.com/ecL4qkqT with the only change added is the single
> > line at the top:
> > /* config.h.  Generated from config.in by configure.  */
> >
> > Details of my environment: win7+msys and I'm trying to build cegcc
> > crosscompiler. The src that I'm using is ok, I built it on Cygwin
> > without that error, yet on msys/mingw it fails at the beginning.
> 
> Which version of MSYS and MinGW packages do you have installed?  In your
> MinGW shell, do you have $PATH set to also point to some Cygwin tools, and if
> yes, please show the value of $PATH, and when you last updated your Cygwin
> installation.
> 
> Can you please download a pristine Autoconf 2.64 tarball from
> ftp.gnu.org/gnu/autoconf and './configure && make && make check' it and
> report back the results, preferably to the bug-autoconf list?
> Thanks.

[Pavel Pavlov] 
I really have no idea what versions I have ;) they at mingw-msys have bunch of installers, plain zip files etc... overall, it's a soup of random bits and I don't know what version of what I have.
I followed this guide to install mingw/msys: http://ffmpeg.arrozcru.org/wiki/index.php?title=MSys_MinGW, there I also took these: GNU Binutils BIN v2.20.1 MinGW Runtime DLL v3.18 MinGW Runtime DEV v3.18 MinGW API for MS-Windows DEV v3.14  and gcc-full-4.4.0-mingw32-bin-2.tar.lzma. Then I installed MSYS-1.0.11.exe coreutils-5.97-MSYS-1.0.11-snapshot.tar.bz2 and I followed this autotools guide: http://ffmpeg.arrozcru.org/wiki/index.php?title=Installling_newest_autotools and built m4-1.4.12. When it didn't work I took m4 from msys sf page but had the same results. Since my config.h mentions autoheader I searched autoheader, which is a perl script. So, I tried to check if there is an issue with perl, tried to replace with activestate-perl but had the same error. After I tried it all I decided to ask on gcc-help and while writing that letter I guessed CRLF issue and that appeared to be source of the problem. When I fixed that I also had other problems and some ppl might be interested to know about that issues:
==
  As part of build of gcc/binutils, there are some temporary executables created that generate some tables. One of that I had problem with was getgtype.c. When it was run as part of build or configure it would simply report something like gengtype.exe input.h No such file or directory  [http://lmgtfy.com/?q=gengtype.exe+input.h+No+such+file+or+directory ]. This problem is also reported all over web, but no clear solution anywhere. The problem was that gengtype while building under msys did not link to msys subsystem, so it can't find /local/whatever/gcc/input.h. While trying to understand what's going on I figured out that msys is similar to cygwin (uses its own file system access library), while mingw uses native win32 access; and the problem was that while building an arm crosscompiler that should run from win32/mingw a temporary executable [gengtype] was built for win32/mingw instead of msys, basically there was some mix-up. I could find out how to properly link to msys subsystem so that gengtype.exe could properly read paths such as "/local/whatever/gcc/inpu.h", but I didn't know quick solution for that, so to fix that problem I had to hardlink (junction in windows) /msys/local to c:\local so that gengtype.exe could open these files and so that I wouldn't need to mess with any code or configs of gcc. I was building cegcc from svn, but I was building gcc based on 4.0.1 because it builds much smaller dll's for arm than the latest cegcc which is based on 4.4.0. SO, I can't tell if the same issu exists in latest or 4.4.0 gcc. I downloaded 4.4.0 src tarball from mingw and looked at their patches to gcc three and saw some proper changes to gcc's tree to properly distinguish mingw and msys or cygwin.
==


Here's the result of make check (from autoconf 2.64):

Summary:
410 tests were successful.
16 tests were skipped.

Skipped tests wrere:

176: parallel test execution                         skipped (autotest.at:1115)
177: parallel truth                                  skipped (autotest.at:1147)
178: parallel fallacy                                skipped (autotest.at:1152)
179: parallel skip                                   skipped (autotest.at:1157)
180: parallel syntax error                           skipped (autotest.at:1162)
181: parallel errexit                                skipped (autotest.at:1181)
182: parallel autotest and signal handling           skipped (autotest.at:1199)

235: AC_PROG_CPP without warnings                    skipped (c.at:146)
236: AC_PROG_CPP via CC                              skipped (c.at:186)

271: Erlang                                          skipped (erlang.at:32)
272: AC_ERLANG_CHECK_LIB                             skipped (erlang.at:54)
273: AC_ERLANG_SUBST_ROOT_DIR                        skipped (erlang.at:74)
274: AC_ERLANG_SUBST_LIB_DIR                         skipped (erlang.at:91)

277: AC_ERLANG_SUBST_ERTS_VER                        skipped (erlang.at:130)

278: AC_CHECK_LIB                                    skipped (semantics.at:35)

425: Libtool                                         skipped (foreign.at:60)


> 
> > I'm absolute ZERO or NULL in that black magic gibberish autoxxx
> > scripts, so I'm asking for your help to resolve that issue. It seems
> > that some of that atotools fail somehow to properly modify/parse some
> > of the input files (CRLF issue maybe?).
> 
> I am probably the one responsible for most of the recent work in that.
> We've tried to make sure that things work well for most setups we can think of
> (and test), but bugs can still happen.  On the upside there was algorithmic
> improvement coming along with the changes.
> 
> > PS: That same problem was once raised on cegcc list but with the same
> > outcome (unresolved):
> > http://www.mail-archive.com/cegcc-devel@lists.sourceforge.net/msg02642
> > .html
> 
> Again, please report to the Autoconf bug list when you suspect a bug in
> Autoconf.  We're glad to hear about reports, even if they turn out to be in other
> pieces of the build system afterwards.
> 
> Thanks,
> Ralf

Re: Problem building gcc

[Ralf Wildenhues]

Hello Pavel,

* Pavel Pavlov wrote on Thu, May 06, 2010 at 07:39:54AM CEST:
> My problem is identical to this one:
> http://gcc.gnu.org/ml/gcc-help/2008-03/msg00044.html
> It fails on configure step of binutils in libiberty. I have no idea
> what's the problem: everything is good, I have all the headers
> installed and I use gcc-4.4.0 as toolset to build crosscompiler.
> 
> In that particular case I have this config.status :
> http://pastebin.com/PSsaya6F
> Yet, the final config.h is absolutely identical to config.in:
> http://pastebin.com/ecL4qkqT with the only change added is the single
> line at the top: 
> /* config.h.  Generated from config.in by configure.  */
> 
> Details of my environment: win7+msys and I'm trying to build cegcc
> crosscompiler. The src that I'm using is ok, I built it on Cygwin
> without that error, yet on msys/mingw it fails at the beginning.

Which version of MSYS and MinGW packages do you have installed?  In your
MinGW shell, do you have $PATH set to also point to some Cygwin tools,
and if yes, please show the value of $PATH, and when you last updated
your Cygwin installation.

Can you please download a pristine Autoconf 2.64 tarball from
ftp.gnu.org/gnu/autoconf and './configure && make && make check' it
and report back the results, preferably to the bug-autoconf list?
Thanks.

> I'm absolute ZERO or NULL in that black magic gibberish autoxxx
> scripts, so I'm asking for your help to resolve that issue. It seems
> that some of that atotools fail somehow to properly modify/parse some
> of the input files (CRLF issue maybe?).

I am probably the one responsible for most of the recent work in that.
We've tried to make sure that things work well for most setups we can
think of (and test), but bugs can still happen.  On the upside there
was algorithmic improvement coming along with the changes.

> PS: That same problem was once raised on cegcc list but with the same
> outcome (unresolved):
> http://www.mail-archive.com/cegcc-devel@lists.sourceforge.net/msg02642.html

Again, please report to the Autoconf bug list when you suspect a bug in
Autoconf.  We're glad to hear about reports, even if they turn out to
be in other pieces of the build system afterwards.

Thanks,
Ralf

RE: Problem building gcc

[Pavel Pavlov]

> Pavel Pavlov <pavel@summit-tech.ca> writes:
> 
> > In that particular case I have this config.status :
> > http://pastebin.com/PSsaya6F Yet, the final config.h is absolutely identical to
> config.in: http://pastebin.com/ecL4qkqT with the only change added is the
> single line at the top:
> > /* config.h.  Generated from config.in by configure.  */
> 
> There is some contradiction there.  The config.status file says HAVE_LIMITS_H
> should be defined.  The config.h file says that it is not defined.
> 
> Precisely which config.status and config.h file did you paste?  There are several
> different files with those names in the build tree.  In particular, did you paste
> files from the same directory?
> 
> The most useful file to look at in these cases is the config.log file.
> Look at the one in the directory whose config.h says that HAVE_LIMITS_H is
> undefined.  Look for the test for whether limits.h is present.  Look for
> compilation errors.

[Pavel Pavlov] 
These are the file that are used. That's clearly a contradiction, definitely some tools are buggy that transform config.in to config.h. I opened config.in converted it to UNIX style line endings and re-run configure and now config.h matches whatever is in config.status. I have no idea how someone managed to break autotools so badly that it can't split CRLF delimited text by LF only. Even if it treated CR as some character then still it should have produced correct results. 
I forced svn line endings to LF now, I never had problems with line endings in Windows/VS tools, but that's not the first time I get that problem in *nix related builds, so I set svn to always use LF to make Cygwin et al happy.

Re: Problem building gcc

[Ian Lance Taylor]

Pavel Pavlov <pavel@summit-tech.ca> writes:

> In that particular case I have this config.status : http://pastebin.com/PSsaya6F
> Yet, the final config.h is absolutely identical to config.in: http://pastebin.com/ecL4qkqT with the only change added is the single line at the top: 
> /* config.h.  Generated from config.in by configure.  */

There is some contradiction there.  The config.status file says
HAVE_LIMITS_H should be defined.  The config.h file says that it is
not defined.

Precisely which config.status and config.h file did you paste?  There
are several different files with those names in the build tree.  In
particular, did you paste files from the same directory?

The most useful file to look at in these cases is the config.log file.
Look at the one in the directory whose config.h says that
HAVE_LIMITS_H is undefined.  Look for the test for whether limits.h is
present.  Look for compilation errors.

Ian

RE: Problem building gcc

[Pavel Pavlov]

...
> asking for your help to resolve that issue. It seems that some of that atotools
> fail somehow to properly modify/parse some of the input files (CRLF issue
> maybe?). 

[Pavel Pavlov] 
That was a correct guess. Some of the tools in the build process will fail or produce wrong results if there are some files with native EOLs

If It was a compilation issue I'd resolve it in no time, but since it's a
> configure failure I even have no idea what's called in what order so that I could
> see what script/program fails.
> 

Problem building gcc

[Pavel Pavlov]

I'm having troubles with gcc build (it's really irrelevant what version I'm building, version itself is ok)
I tried to google, and I see similar problem reported all over the web, but nobody ever finally got it resolved.

My problem is identical to this one: http://gcc.gnu.org/ml/gcc-help/2008-03/msg00044.html
It fails on configure step of binutils in libiberty. I have no idea what's the problem: everything is good, I have all the headers installed and I use gcc-4.4.0 as toolset to build crosscompiler.

In that particular case I have this config.status : http://pastebin.com/PSsaya6F
Yet, the final config.h is absolutely identical to config.in: http://pastebin.com/ecL4qkqT with the only change added is the single line at the top: 
/* config.h.  Generated from config.in by configure.  */

Details of my environment: win7+msys and I'm trying to build cegcc crosscompiler. The src that I'm using is ok, I built it on Cygwin without that error, yet on msys/mingw it fails at the beginning.


I'm absolute ZERO or NULL in that black magic gibberish autoxxx scripts, so I'm asking for your help to resolve that issue. It seems that some of that atotools fail somehow to properly modify/parse some of the input files (CRLF issue maybe?). If It was a compilation issue I'd resolve it in no time, but since it's a configure failure I even have no idea what's called in what order so that I could see what script/program fails.

Than you

PS: That same problem was once raised on cegcc list but with the same outcome (unresolved): http://www.mail-archive.com/cegcc-devel@lists.sourceforge.net/msg02642.html

Re: problem building gcc

[Brian Dessent]

collinr@ensisun.imag.fr wrote:

> I made "./configure" in GCC subdirectory (OK) then

You must run the configure script at the toplevel, not in the gcc
subdirectory.  Also, building in the source directory is not
recommended, please see the install directions.

Brian

problem building gcc

[collinr]

Good morning,
I had a problem while trying to build GCC (version 4.3.1) with Cygwin.
I made "./configure" in GCC subdirectory (OK) then
I made "make all"    in GCC subdirectory (KO).
It is said the file build/genmodes.exe is missing. I saw on the  
Internet I am not the first one to have this problem, but I did not  
find the solution, could you tell me what to do?

I have an another problem in gcc-4.3.1-directory :
"./configure" works, but command "make" encounter errors. The trace of  
command "make" shows a lot of "undefined reference to" (about 100).

Do I need to make something in gcc-4.3.1 directory to build gcc, or I  
can do everything in gcc subdirectory?


Regards,
Rémi Collin

Re: Problem building GCC

[Alexandre Oliva]

On Nov  2, 2000, Andrew Dumaresq <Andrew.Dumaresq@stmarys.ca> wrote:

> I am using Tru64 Unix and using the default
> make and utils for that OS.

You failed to mention it was Tru64 5.0, which is not supported by GCC
2.95.2.  I heard there are patches floating around that fix this minor
problem, but I don't know whether there are any more significant
changes needed.

If someone collects the patches and send them to gcc-patches, I'd be
glad to add them to the system-specific installation notes.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Problem building GCC

[Andrew Dumaresq]

I have a DEC 3000 Model 400, that I wanted to put linux on but I can't,
aprently the bus is messy. :) Anyway I was trying to compile GCC on this
machine and I run into the following error:

I have un tarred the source to /usr/src/gcc-2.95.2 and made a dir
/usr/src/obj I goto /usr/src/obj and type
/usr/scr/gcc-2.95.2/configure.  The configure runs fine, but when I type
make bootstrap I get the above error.  I'm sure this is something simple
but I can't figure it out. I am using Tru64 Unix and using the default
make and utils for that OS.

cc  -DIN_GCC -DHAIFA    -g   -DHAVE_CONFIG_H  -o cc1 toplev.o version.o
tree.o print-tree.o stor-layout.o fold-const.o  function.o stmt.o
except.o expr.o calls.o expmed.o explow.o optabs.o  intl.o varasm.o
rtl.o print-rtl.o rtlanal.o emit-rtl.o genrtl.o real.o  dbxout.o
sdbout.o dwarfout.o dwarf2out.o xcoffout.o bitmap.o alias.o gcse.o
integrate.o jump.o cse.o loop.o unroll.o flow.o stupid.o combine.o
varray.o  regclass.o regmove.o local-alloc.o global.o reload.o reload1.o
caller-save.o  insn-peep.o reorg.o haifa-sched.o final.o recog.o
reg-stack.o  insn-opinit.o insn-recog.o insn-extract.o insn-output.o
insn-emit.o lcm.o  profile.o insn-attrtab.o alpha.o getpwd.o  convert.o
mbchar.o dyn-string.o splay-tree.o graph.o sbitmap.o resource.o hash.o
c-parse.o c-lang.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o
c-aux-info.o c-common.o c-iterate.o  obstack.o       -lmld
../libiberty/libiberty.a
ld:
Unresolved:
ASM_FILE_START
*** Exit 1
Stop.
*** Exit 1
Stop.
*** Exit 1
Stop.

I hope this is enough info

Thanks
Andrew Dumaresq

--
Andrew Dumaresq
Technician
Mathematics & Computing Science
Saint Mary's University
Phone: (902)420-5893
Fax: (902)420-5035