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]

GCC 2.95.2 solaris -> powerpc-wrs-vxworks



I've spent the past few days trying to produce a solaris ->
powerpc-wrs-vxworks 
cross compiler for Vxworks 5.3.1but without much success.

I compiled binutils 2.9.1 (with a powerpc patch) and
it configured and compiled with no problems.

GCC2.95.2, on the other hand, didn't get that far. gmake LANGUAGES="c c++" 
failed on the target all-target-libiberty because of a conflict in a header
file  
(they had #defined TIME).

This was past the point where libgcc.a and the compiler were built, so I
went to 
the install stage:

gmake install:

That produced:
install:  _G_config.h does not exist.

But the compiler was installed in the prefix dir before this failure, so I 
decided to try testing it. I recompiled a board support package using 
the compiler, and except for the fact that this compiler is pickier than
the last and gave some warnings, everything was fine. However, the 
computer locked up trying to boot this bsp. I traced it to the fact that, 
at the last link step, the 2.9.1 ld was not correctly generating the sizes 
of some items in the object files.  (The addresses listed by nm
--numeric-sort
did not agree with the sizes listed by nm --size-sort. The erroneous entries

were all 'S' entries; i.e. in the uninitialized data section for small
objects.) 
Is this a known bug in 2.9.1 ld when built for powerpc-wrs-vxworks?

Using the WRS supplied 2.6 ld at the last link step (i.e. without -r)
worked,
and allowed the board to boot.

Another issue:  this compiler produced static constructor initialization
stubs 
that were local, not global.  (This made it impossible to 'munch' the file
and produce 
the vxworks standard _ctors & _dtors lists, because the linker wouldn't
resolve
the references to the stubs.)  The -fno-gnu-linker and -fgnu-linker options
to 
g++ didn't change anything about the  generated object file. 

This has been an adventure.... I guess I can't blame
Wind River for not updating the compilers more often.....

Thanks,
Rod Freier
#include <std_disclaimer>



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