This is the mail archive of the crossgcc@sourceware.cygnus.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more infromation.


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

Re: broken link for libstdc++.a


Stephane Dalton wrote:
> 
>         [Stephane Dalton]  Ok lets make everything clear
>         target m68k-elf
>         binutils 2.9.1 installed
>         gcc installed
>         g++ installed but missing libstdc++.a
> 
>         Here's what I've tried
>         I modified my specs file (the one which is used during the
> compilation of the compiler not the one which is in /usr/local/lib...
>         Results: make is trying to compile the libgcc1-test.c and link it,
> but even using the -nostartfiles it seems that the linker fetch the crt0.o
>         which is not a good idea because the start symbol is already defined
> in libgcc1-test.c but not the main symbol which is required by crt0.o
> 
>         Correct me if I'm wrong but I see no clean way to get out of this
> problem, on one side the configure script wants to build this stupid
> libgcc1-test program and it seems that at this point the compiler doesn't
> recognize the -nostartupfiles and that's probably why there's nothing under
> the entry *link in the spec file at this point. On the other side to compile
> libiberty and libstdc++ I need a crt0.o and I have it. The only thing I can
> try is to hack the configure script to modify the specs file at a given
> point.

 When you now mentioned this, I remembered there being a problem... My
'libgcc1-test.c' has in the end :

------------------------ clip
-------------------------------------------------
#if !defined (mc68000) && !defined (sparclite)

/* Provide functions that might be needed by soft-float emulation
routines.  */
void memcpy() {}

void start() {}
void _start() {}
void __start() {}
void mainCRTStartup() {}

#else

int
main()
{
    main_without__main ();
    return 0;
}

#endif
------------------------ clip
-------------------------------------------------

 But I cannot remember where I got this 'fix'... It may be that it was
with the
older GCCs but then somehow dropped away. As you can see, also the
'sparclite'
has just the same problem.

>         And BTW am I the only one trying to compile this thing and having
> such amout of problems???

 Not at all, people are just lazy to write 'bug' reports and after
getting some
experience all the problems will go unnoticed, things like fixing the
'specs' or
the 'libgcc1-test.c' will perhaps cause a little frustration... "Why on
earth
nobody hasn't fixed this yet !"   The 'libgcc1-test.c' at least could be
fixed,
but perhaps the previous breaks the 'm68k-linux-gnu' or some other
target...

  But if thinking the 'bugs' more, the idea of them being 'a way to
teach
something', e.g. the need to have a startup, a glue library for the
target
board and a linker script telling where the memory is, all this sounds
to be
quite essential know-how for an embedded engineer. Perhaps they are
there
to test if these things really are already known.

 Those targets which have a default 'target board', quite often the
simulator
coming with GDB, will be easy to build, but one can wonder how on earth
the
user will become aware about the need of a specific startup and the need
to
rewrite the low-level-I/O for some 'non-standard' board...

 My opinion is that the m68k and PowerPC could also have a default
target, but
somewhere there should be a warning and explanation what must be done
when
using the toolset for other than the default target board.... (A
README.EMBED
or something...) Then the GCC build would succeed more cleanly...

 Quite many troubles come from not knowing yet those 'debug the GCC
installation'
options like '--help', '-v', '-print-search-dirs', '-Wl,-verbose' etc.
BTW, I
have written about using the '-print-search-dirs' for seeing why it
cannot find
the target headers, but nobody hasn't yet replied that it really doesn't
show
the search paths for the headers... If so, everybody has understood that
the
search paths for them follow quite well the ones for 'programs' and
'libraries',
which the '-print-search-dirs' gives. Just replace the 'bin' or 'lib' in
them
with 'include'... The exception is the 'install' directory, also given
with the
option, there the headers are in the 'include' subdir while the programs
and
libs are in the 'install' directory....


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


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