RE: broken link for libstdc++.a

[Stephane Dalton <Stephane dot Dalton at abl dot ca>]

>  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
> -------------------------------------------------
	[Stephane Dalton]  Ok this is one of the thing that I partially
tried after sending my email, but it didn't seem to do the job, anyway I'll
give it another try just to make sure. 
>  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.
	[Stephane Dalton]  Ok thanks for the hint!

> >         And BTW am I the only one trying to compile this thing and
> having
> > such amout of problems???
> 
>   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.
	[Stephane Dalton]  Interesting opinion but I would prefer learn
something in more appropriated time not when I REALLY need this thing to
work... but I've to say that I'm enjoying playing with all this!!! That's my
situation, the problem is I'm trying to change our commercial tool and make
the firmware departement adopt gnu tools and Linux, it's a quite delicate
situation.

>  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....
	[Stephane Dalton]  I read your previous mail, and I've read the
Using and Porting GCC so be assured that I know what is the -v switch added
to --help :)

	Thanks for your help Kai, I'll keep you informed of future
developpement and thanks to other people trying to help me, after all of
this is working I PROMISE I'll write a kind of howto and I'll keep it up to
date, so if you think of a place where such a document can be uploaded
(perhaps the cross gcc faq??) let me know!

	bye



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