This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: problem building newlib (was RE: 68000 cross compiler under windows 2000)


> 
> Bruce Adams wrote:
> > > Is that the acgeneral.m4 patch I posted recently?  If so, did you
> > > also regenerate gcc/configure with autoconf?
> >
> >   It is the very same.  I trashed the whole crossgcc build directory
> > and started again from scratch is that good enough? :-)
> 
> No.  You have to rerun autoconf *in the gcc and libiberty 
> subdirectories
> of the gcc source tree* before you configure gcc.  
> Furthermore, when you make gcc, you have to do it as follows:
>     make all-gcc
>     ac_cv_prog_cc_cross=yes cross_compiling=yes make all-target
>     make install
> in order for that patch to do any good.
>
Thanks.  I missed that step out.  
If we have to specify this during the build what exactly does the patch 
do for us?

> > I never saw the bug you were originally describing (with the dialogs
> > and all that) but this does seem that wrong 'as' is being invoked.
> > Its the same message I get from running 'as -m68000' instead of
> > 'm68k-coff-as -m68000'.  It looks like its calling m68k-coff-gcc so
> > I guess something went wrong there.  I have only one acgeneral.m4
> > on that machine.  Drat, drat & triple drat!
> 
> acgeneral.m4 is only used when running the program 'autoconf', which
> produces the 'configure' scripts in the gcc source tree 
> subdirectories.
> It is not used during 'configure' or 'make'.
>
Okay.  I've been spending too long in windows land.  So much so I am using
a dos prompt rather than the bash shell.  I remembered how to run autoconf
eventually (from Dos its on your path but not executable because there's no
extension).  If you think that's bad where I work GNU's not UNIX but some
kind of antelope.
 
> You can tell if you need my patch by examining the contents of
> m68000/config.cache (or whatever your arch directory is called)
> after making gcc.  If it contains the line
> ac_cv_prog_cc_cross=${ac_cv_prog_cc_cross='no'}
> you have the bug.  If not, you're fine, and don't need the patch.
> 
> - Dan
> 
Well I definitely have the bug.  With the patch in place the cached value
is still no.  Is this expected?

I think something else may need re-autoconfing (not a verb you use everyday)
because it still fails building newlib, though the error has moved to
libc/stdlib/__adjust.c.  This seems to be earlier than before!

If I run m68k-coff-gcc -m68000 __adjust.c I don't get the invalid option
error but I do if I run plain gcc.  Strangely I also get the error if I put
the build line that fails in a bash script.  

m68k-coff-gcc
-B/cygdrive/c/BruceA/DOWNLO~1/gcc/crossgcc/build-newlib/m68k-coff/m68000/new
lib/ -isystem
/cygdrive/c/BruceA/DOWNLO~1/gcc/crossgcc/build-newlib/m68k-coff/m68000/newli
b/targ-include -isystem
/cygdrive/c/BruceA/DOWNLO~1/gcc/crossgcc/newlib-1.10.0/newlib/libc/include
-m68000 -DPACKAGE=\"newlib\" -DVERSION=\"1.10.0\"  -I.
-I../../../../../../newlib-1.10.0/newlib/libc/stdlib  -O2
-DMISSING_SYSCALL_NAMES -I../../targ-include
-I../../../../../../newlib-1.10.0/newlib/libc/../libc/include -fno-builtin
-g -O2 -c ../../../../../../newlib-1.10.0/newlib/libc/stdlib/__adjust.c

Bit of a long line.  Could this be causing a problem for the shell?  If you
put it
in a DumestOS batch file it just goes "no input file" but we know a loathe
DOS's 
limitations already.

If I enter newlib-1.10.0 directly instead of using it from a separate
build-newlib
directory then I can configure and build in the newlib directory but
configure at the toplevel fails.  This is of course no good to me because it
builds newlib for cygwin
and not for m68k-coff.  
I'm used to configuring and building directly in the untarred directory
rather than in a separate one.  Why does one work (sort of) and not the
other.
Configure doesn't run from the newlib-1.10.0/m68k-coff/newlib sub-directory
perhaps because everything is a pretend symbolic link (.lnk).  This is true
whether you try in bash or from DOS.

So where do I go from here?
                          Regards,
					    Bruce A.




============================================================================
 Any opinions expressed in this e-mail are those of the individual and not
 necessarily those of Tyco Electronic Product Group.

 Any prices for the supply of goods or services are only valid if supported
 by a formal written quotation.

 This e-mail and any files transmitted with it, including replies and
 forwarded copies (which may contain alterations) subsequently transmitted
 from Tyco Electronic Product Group are confidential and solely for the use
 of the intended recipient.

 If you are not the intended recipient or the person responsible for
 delivery to the intended recipient, be advised that you have received this
 e-mail in error and that any use is strictly prohibited.  In this event,
 please notify us via e-mail at 'helpdesk.tepg@tycoint.com' or telephone on 
 0121 255 6499 and then delete the e-mail and any copies of it.
============================================================================






------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]