Dependencies when using gcc-generated object files in another compiler
Lehner, Michael
michaellehner@siemens.com
Tue Jan 9 14:30:00 GMT 2007
> >
> > >>>>> "Michael" == Lehner, Michael <michaellehner@siemens.com> writes:
> >
> > Michael> I read something about an option for gcc to use Greenhills ABI,
> > but I
> > Michael> didn't figure out how to use it and if it's really supported,
> > does
> > Michael> anybody know?
> >
> > I don't see anything in the documentation about this.
> >
> [Lehner, Michael]
> It was on a mailing list, but there also was no solution.
[Lehner, Michael]
The first Problem is solved, GHS seems to be able tu use the GNU objects.
>> > Michael> And our intention was even to use java for our
> > Michael> operating-system-development. That means we must be able to
> > Michael> compile it for MIPS itself and not for an specific operating
> > Michael> system.
> >
> > This can be done -- we've done it before -- but it will require you to
> > do some porting work on the GC and libgcj itself.
> >
> [Lehner, Michael]
> But i think it won't be possible to evaluate how much porting work I will
> have to do I think?
>> > I looked briefly at your original note...
> >
> > >> > __gcj_personality_v0 from Main.o
> > >> > _Unwind_Resume from gnulib.a(Class.o)
> > >> > _Jv_Throw from gnulib.a(Class.o)
> >
> > Missing libgcj's exception code somehow?
> >
> > >> > __fixdfdi from gnulib.a(lt15-lang.o)
> > >> > __fixsfdi from gnulib.a(lt15-lang.o)
> >
> > Missing libgcc?
> >
> > >> > _ZN4java4util5regex7Pattern7compileEPNS_4lang6StringE from
> > >> gnulib.a(lt15-lang.o)
> >
> > Did you remove parts of libgcj but not update the callers?
> >
> [Lehner, Michael]
> No, I took the original classpath included in gcc-4.1.1 and did not change
> anything. Strange to me is also, that if I only use gcc without
> Greenhills, I get an executable without any problems. I took all .o and .a
> files in the lib-dir of the cross compiler I am using. Extracted the
> archives and copied the objects into the same dir. Then I made a big
> archive out of all the files and told the Greenhills linker, to search in
> this archive too.
> Problems occurred extracting libieee.a and libmcheck.a, ar tells me, that
> File format is not recognized. And I had to remove mcheck.o, strtoll_l.o,
> strtoull_l.o strtoul_l.o and vfprintf.o, because Greenhills said to me,
> that there are symbols hat already defined in another object.
> Is there anything missing I would perhaps need for successfully compiling?
>> > Anyway, to make this stuff work you'll have to dive into the guts a
> > bit. And, things could be especially problematic if your OS is
> > written in C++ and throws exceptions that the caller must catch. A
> > lot depends on the details of the GH compiler, about which I know
> > nothing.
> >
> [Lehner, Michael]
> The OS itself is not written in C++, it is written in C, but there are a
> few higher parts where C++ is used besides C. I don't know if this could
> mean problems, but I think I will see. First I will have to solve the
> current Problems.
>> Michael
[Lehner, Michael]
The errors while linking have changed now, a bit, I have 40 unresolved symbols in the moment. But I don't know why they decreased. I had made one big archive with all the objects in the libs path of my compiler, because I must append every file I use to the memory map by hand. But when I also add libgcj.a to the linker options I loose 19 errors, I don't understand why, because all objects in libgcj.a are also in my new big library. Is there any reason for this behavior?
But more important to me is the question if there is a way to figure out which objects the linker ties into the resulting executable and because of which symbol, because I really don't understand why linking with GNU works without any errors and linking with GHS and all the objects I used for GNU throws me 40 errors.
Am I right when I think the porting work for our operating system will not influence the possibility of translating and linking my project, but only will cause it to crash at runtime or something like that?
Yours sincerely
Mit freundlichen Grüßen
Michael Lehner
Siemens AG
Automation and Drives
Industrial Automation Systems
A&D AS RD
Werner-von-Siemens Str. 50
92224 Amberg, Germany
Tel.: +49 9621 80-5209
michael.lehner@siemens.com
Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Heinrich v. Pierer;
Vorstand: Klaus Kleinfeld, Vorsitzender; Johannes Feldmayer, Joe Kaeser, Rudi Lamprecht, Eduardo Montes, Jürgen Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. Sharef, Klaus Wucherer
Sitz der Gesellschaft: Berlin und München
Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684
WEEE-Reg.-Nr. DE 23691322
More information about the Java
mailing list