You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by David Tanzer <st...@guglhupf.net> on 2005/11/22 21:38:22 UTC
[jchevm] Porting JCHEVM to OSX/PPC
Hi All,
Is there anybody still working on an OSX/PPC port of JCHEVM? I tried to
compile it on my iBook today and looked a little bit into it, but I'll
not be able to do the port without some help. I read through the
discussion which followed Archie Cobbs's announcement of the
contribution [1] where Andy Oliver tried to port it, but I didn't find
all the answers there. I don't really have experience with arch-specific
stuff or porting to OSX/PPC, so if there's someone who wants to do the
port instead of me I wouldn't mind too.
First of all the problem with the missing "elf.h". Simply copying it
from a Linux system doesn't do the job (elf.h has other dependencies,
and I didn't want to copy too much headers). Can I remove all the ELF
specific stuff? I started doing so, it looks like a lot of work but
AFAICS the ELF stuff isn't used anyway in the harmony edition.
I saw that there is the following construct in some of the header files:
#elif defined(__powerpc__)
#include "powerpc/powerpc_[some-header].h
#endif
which I extended to:
#elif defined(__powerpc__)
#include "powerpc/powerpc_[some-header].h
#elif defined(__ppc__)
#include "ppc/ppc_[some-header].h
#endif
and added the appropriate headers (see next paragraph). Is there a
powerpc-port of the original JCVM and could we use it for harmony?
In the directory libjc/arch/ppc i added ppc_definitions.h,
ppc_structures.h and ppc_libjc.h. I simply copied the files from the
i386 directory and used the FreeBSD - Specific stuff where there were OS
differences. This doesn't work for "ppc_libjc.h". Here the structure
mcontext_t is not defined. Where does that come from on i386?
Regards,
David
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/%3c4337017B.4090003@dellroad.org%3e
--
David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe
http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net
My PGP Public Key: http://guglhupf.net/david/david.asc
--
From "Meet John Brain"
Brain: Pinky, once I take over the world, remind me to publicly snub you.
Re: [jchevm] Porting JCHEVM to OSX/PPC
Posted by David Tanzer <st...@guglhupf.net>.
On Tue, 2005-11-29 at 17:56 -0600, Archie Cobbs wrote:
> David Tanzer wrote:
> > Good Idea, but where would I place that branch?
> > "harmony/enhanced/branches/sandbox/contribs/jchevm/osx_port"?
>
> I don't know what the policy is (probably there isn't one :-)
Ok, @All: Is there a policy? Should there be one?
Cheers, David.
--
David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe
http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net
My PGP Public Key: http://guglhupf.net/david/david.asc
--
METHODEN DER BEWEISFHRUNG -- PRZISE BEZEICHNUNGEN
Sei p ein Punkt q, wir wollen ihn als "r" bezeichnen.
Re: [jchevm] Porting JCHEVM to OSX/PPC
Posted by Archie Cobbs <ar...@dellroad.org>.
David Tanzer wrote:
> Good Idea, but where would I place that branch?
> "harmony/enhanced/branches/sandbox/contribs/jchevm/osx_port"?
I don't know what the policy is (probably there isn't one :-)
I'd guess anywhere underneath "sandbox" is OK. E.g., you could
create harmony/enhanced/branches/sandbox/dtanzer or whatever.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: Where do we put it? (Was Re: [jchevm] Porting JCHEVM to OSX/PPC)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Dec 5, 2005, at 11:48 AM, Archie Cobbs wrote:
> Geir Magnusson Jr. wrote:
>> On Dec 5, 2005, at 10:17 AM, Archie Cobbs wrote:
>>> Geir Magnusson Jr. wrote:
>>>
>>>>>>> I stripped out lots of ELF specific stuff, so my version
>>>>>>> could be
>>>>>>> interesting for a port to windows too. I just don't want to
>>>>>>> commit it
>>>>>>> to "trunk" yet because it's completely untested.
>>>>>>
>>>>>>
>>>>>> You could create a branch to play with in Subversion. If you do,
>>>>>> I recommend also using svnmerge... http://dellroad.org/svnmerge
>>>>>
>>>>>
>>>>> Good Idea, but where would I place that branch?
>>>>> "harmony/enhanced/branches/sandbox/contribs/jchevm/osx_port"?
>>>>>
>>>>> I'll look at the rest of the issues later...
>>>>
>>>> Is there a way to safely get this code in the main trunk? I
>>>> don't mind (what about others?) if you need to work in the
>>>> corner of the sandbox, but this seems like enhancement to the
>>>> trunk rather than a revolutionary experiment...
>>>
>>>
>>> That's OK with me, but since it's still "completely untested" it
>>> seems
>>> like a branch may be better... but in any case, if there is some
>>> uncertainy,
>>> why not create a branch? Branches are essentially zero cost with
>>> Subversion,
>>> even if it's only for a short while to get things "in order", etc.
>> How about testing it? :)
>
> Sure.. but for that to happen, the patches have to be committed
> somewhere
> first (let's try to avoid emailing patches around and use SVN
> instead).
The developer should test locally first. If it's a matter of the
developer not having the platform to test on, that's another story.
>
>> I believe that the changes shouldn't break jcheVM on platforms
>> other than OSX/PPC, but if they don't work yet on OSX/PPC, that's
>> fine. If that can't be done - if David can't do that, then
>> maybe a sandbox is right, but at some point, it *has* to come
>> back to the tree, which means that it doesn't break the existing
>> code, and I think that if we can do that now in the trunk that's
>> better.
>
> OK, that's fine with me.
>
>> We'd like to have a culture of "check in stuff that doesn't break
>> others", but "commit early and often so others can see and work
>> with what you are doing"
>
> I couldn't agree more. This is exactly what branches allow you to
> do :-)
Yes, but then you aren't working together on the codebase :)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Where do we put it? (Was Re: [jchevm] Porting JCHEVM to OSX/PPC)
Posted by Archie Cobbs <ar...@dellroad.org>.
Geir Magnusson Jr. wrote:
>
> On Dec 5, 2005, at 10:17 AM, Archie Cobbs wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>>>>> I stripped out lots of ELF specific stuff, so my version could be
>>>>>> interesting for a port to windows too. I just don't want to
>>>>>> commit it
>>>>>> to "trunk" yet because it's completely untested.
>>>>>
>>>>>
>>>>> You could create a branch to play with in Subversion. If you do,
>>>>> I recommend also using svnmerge... http://dellroad.org/svnmerge
>>>>
>>>>
>>>> Good Idea, but where would I place that branch?
>>>> "harmony/enhanced/branches/sandbox/contribs/jchevm/osx_port"?
>>>>
>>>> I'll look at the rest of the issues later...
>>>
>>> Is there a way to safely get this code in the main trunk? I don't
>>> mind (what about others?) if you need to work in the corner of the
>>> sandbox, but this seems like enhancement to the trunk rather than a
>>> revolutionary experiment...
>>
>>
>> That's OK with me, but since it's still "completely untested" it seems
>> like a branch may be better... but in any case, if there is some
>> uncertainy,
>> why not create a branch? Branches are essentially zero cost with
>> Subversion,
>> even if it's only for a short while to get things "in order", etc.
>
> How about testing it? :)
Sure.. but for that to happen, the patches have to be committed somewhere
first (let's try to avoid emailing patches around and use SVN instead).
> I believe that the changes shouldn't break jcheVM on platforms other
> than OSX/PPC, but if they don't work yet on OSX/PPC, that's fine. If
> that can't be done - if David can't do that, then maybe a sandbox is
> right, but at some point, it *has* to come back to the tree, which
> means that it doesn't break the existing code, and I think that if we
> can do that now in the trunk that's better.
OK, that's fine with me.
> We'd like to have a culture of "check in stuff that doesn't break
> others", but "commit early and often so others can see and work with
> what you are doing"
I couldn't agree more. This is exactly what branches allow you to do :-)
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: Where do we put it? (Was Re: [jchevm] Porting JCHEVM to OSX/PPC)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Dec 5, 2005, at 10:17 AM, Archie Cobbs wrote:
> Geir Magnusson Jr. wrote:
>>>>> I stripped out lots of ELF specific stuff, so my version could be
>>>>> interesting for a port to windows too. I just don't want to
>>>>> commit it
>>>>> to "trunk" yet because it's completely untested.
>>>>
>>>> You could create a branch to play with in Subversion. If you do,
>>>> I recommend also using svnmerge... http://dellroad.org/svnmerge
>>>
>>> Good Idea, but where would I place that branch?
>>> "harmony/enhanced/branches/sandbox/contribs/jchevm/osx_port"?
>>>
>>> I'll look at the rest of the issues later...
>> Is there a way to safely get this code in the main trunk? I
>> don't mind (what about others?) if you need to work in the corner
>> of the sandbox, but this seems like enhancement to the trunk
>> rather than a revolutionary experiment...
>
> That's OK with me, but since it's still "completely untested" it seems
> like a branch may be better... but in any case, if there is some
> uncertainy,
> why not create a branch? Branches are essentially zero cost with
> Subversion,
> even if it's only for a short while to get things "in order", etc.
How about testing it? :)
I believe that the changes shouldn't break jcheVM on platforms other
than OSX/PPC, but if they don't work yet on OSX/PPC, that's fine.
If that can't be done - if David can't do that, then maybe a sandbox
is right, but at some point, it *has* to come back to the tree, which
means that it doesn't break the existing code, and I think that if we
can do that now in the trunk that's better.
We'd like to have a culture of "check in stuff that doesn't break
others", but "commit early and often so others can see and work with
what you are doing"
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Where do we put it? (Was Re: [jchevm] Porting JCHEVM to OSX/PPC)
Posted by Archie Cobbs <ar...@dellroad.org>.
Geir Magnusson Jr. wrote:
>>>> I stripped out lots of ELF specific stuff, so my version could be
>>>> interesting for a port to windows too. I just don't want to commit it
>>>> to "trunk" yet because it's completely untested.
>>>
>>> You could create a branch to play with in Subversion. If you do,
>>> I recommend also using svnmerge... http://dellroad.org/svnmerge
>>
>> Good Idea, but where would I place that branch?
>> "harmony/enhanced/branches/sandbox/contribs/jchevm/osx_port"?
>>
>> I'll look at the rest of the issues later...
>
> Is there a way to safely get this code in the main trunk? I don't mind
> (what about others?) if you need to work in the corner of the sandbox,
> but this seems like enhancement to the trunk rather than a
> revolutionary experiment...
That's OK with me, but since it's still "completely untested" it seems
like a branch may be better... but in any case, if there is some uncertainy,
why not create a branch? Branches are essentially zero cost with Subversion,
even if it's only for a short while to get things "in order", etc.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: Where do we put it? (Was Re: [jchevm] Porting JCHEVM to OSX/PPC)
Posted by David Tanzer <st...@guglhupf.net>.
On Dec 5, 2005, at 3:41 PM, Geir Magnusson Jr. wrote:
> Sorry to interrupt with a technical issue...
>
> On Nov 29, 2005, at 6:48 PM, David Tanzer wrote:
>
>> On Tue, 2005-11-29 at 16:34 -0600, Archie Cobbs wrote:
>> [...]
>>>> I stripped out lots of ELF specific stuff, so my version could be
>>>> interesting for a port to windows too. I just don't want to
>>>> commit it
>>>> to "trunk" yet because it's completely untested.
>>>
>>> You could create a branch to play with in Subversion. If you do,
>>> I recommend also using svnmerge... http://dellroad.org/svnmerge
>>
>> Good Idea, but where would I place that branch?
>> "harmony/enhanced/branches/sandbox/contribs/jchevm/osx_port"?
>>
>> I'll look at the rest of the issues later...
>
> Is there a way to safely get this code in the main trunk? I don't
> mind (what about others?) if you need to work in the corner of the
> sandbox, but this seems like enhancement to the trunk rather than a
> revolutionary experiment...
I guess it wouldn't cause too much problems committing it to trunk
since we could
always revert to the base revision if something goes wrong. The real
question is:
Do we have/need a SVN policy? How would it look like?
Wherever I've worked with version control before there always were
rules like:
"Never break the build in trunk" or
"Only unit-tested code goes to trunk"
and similar. I just wanted to ask before I do something wrong...
Cheers, David.
> geir
>
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
Where do we put it? (Was Re: [jchevm] Porting JCHEVM to OSX/PPC)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Sorry to interrupt with a technical issue...
On Nov 29, 2005, at 6:48 PM, David Tanzer wrote:
> On Tue, 2005-11-29 at 16:34 -0600, Archie Cobbs wrote:
> [...]
>>> I stripped out lots of ELF specific stuff, so my version could be
>>> interesting for a port to windows too. I just don't want to
>>> commit it
>>> to "trunk" yet because it's completely untested.
>>
>> You could create a branch to play with in Subversion. If you do,
>> I recommend also using svnmerge... http://dellroad.org/svnmerge
>
> Good Idea, but where would I place that branch?
> "harmony/enhanced/branches/sandbox/contribs/jchevm/osx_port"?
>
> I'll look at the rest of the issues later...
Is there a way to safely get this code in the main trunk? I don't
mind (what about others?) if you need to work in the corner of the
sandbox, but this seems like enhancement to the trunk rather than a
revolutionary experiment...
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [jchevm] Porting JCHEVM to OSX/PPC
Posted by David Tanzer <st...@guglhupf.net>.
On Tue, 2005-11-29 at 16:34 -0600, Archie Cobbs wrote:
[...]
> > I stripped out lots of ELF specific stuff, so my version could be
> > interesting for a port to windows too. I just don't want to commit it
> > to "trunk" yet because it's completely untested.
>
> You could create a branch to play with in Subversion. If you do,
> I recommend also using svnmerge... http://dellroad.org/svnmerge
Good Idea, but where would I place that branch?
"harmony/enhanced/branches/sandbox/contribs/jchevm/osx_port"?
I'll look at the rest of the issues later...
Cheers, David.
--
David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe
http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net
My PGP Public Key: http://guglhupf.net/david/david.asc
--
Jeden Tag vorm Einschlafen des Biosavard-Gesetz. Eh klar, do seid ihr
high und happy.
-- F. Hoislbauer
Re: [jchevm] Porting JCHEVM to OSX/PPC
Posted by Dudley Flanders <du...@misnomer.us>.
On Nov 29, 2005, at 4:34 PM, Archie Cobbs wrote:
> David Tanzer wrote:
>> The good news first: it compiles now. The problem I described in the
>> previous mail was that libjc was linked with the option "-module" (so
>> it can be dlopen()ed) and this is not portable. I removed the -module
>> and now it compiles.
>> I stripped out lots of ELF specific stuff, so my version could be
>> interesting for a port to windows too. I just don't want to commit it
>> to "trunk" yet because it's completely untested.
>
> You could create a branch to play with in Subversion. If you do,
> I recommend also using svnmerge... http://dellroad.org/svnmerge
As an alternative to branching on the main repository, you might want to
check out svk (http://svk.elixus.org/). It'll let you create a local
branch
on your own machine to play with which you can later merge back to the
trunk.
-dudley
Re: [jchevm] Porting JCHEVM to OSX/PPC
Posted by Archie Cobbs <ar...@dellroad.org>.
David Tanzer wrote:
> The good news first: it compiles now. The problem I described in the
> previous mail was that libjc was linked with the option "-module" (so
> it can be dlopen()ed) and this is not portable. I removed the -module
> and now it compiles.
>
> I stripped out lots of ELF specific stuff, so my version could be
> interesting for a port to windows too. I just don't want to commit it
> to "trunk" yet because it's completely untested.
You could create a branch to play with in Subversion. If you do,
I recommend also using svnmerge... http://dellroad.org/svnmerge
> @Archie Cobbs: Is the "-module" really important for libjc? If yes we'd
> have to find a portable solution for this...
JC dlopen()s itself in order to access core native code for java.lang,
etc. This code in turn accesses core VM functions. It's possible to avoid
this; e.g., you could add a special hack in JC's native linker along with
a static (and redundant) array of available native functions. This would
be easy to do but imposes a maintenance burden because this list must
be kept up to date with the functions defined in libjc/native/*.c.
> To make it compile I left the funtion "_jc_dynamic_invoke(...)" in the
> file "libjc/arc/ppc/arch_functions.c" empty, but this function is needed
> to run JCHEVM (it calls C functions and is needed for JNI AFAICS). Maybe
> somebody with more PPC experience can help me with porting this function
> from i386.
That function essentially does the same thing as libffi (but slightly
differently of course :-) You might look at libffi's implementation.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: [jchevm] Porting JCHEVM to OSX/PPC
Posted by Enrico Migliore <en...@fatti.com>.
>The good news first: it compiles now. The problem I described in the
>previous mail was that libjc was linked with the option "-module" (so
>it can be dlopen()ed) and this is not portable. I removed the -module
>and now it compiles.
>
>I stripped out lots of ELF specific stuff, so my version could be
>interesting for a port to windows too. I just don't want to commit it
>to "trunk" yet because it's completely untested.
>
>
>
Hi David,
I'm trying to compile JCHEVM with MSVC but, at the moment, the work, as
underlined
by Archie, last week, is not trivial and in fact, I'm having a
noticeable number of compiling errors.
Next week, I'm gonna try to use the native port of the GNU chain, MinGW,
as suggested by Ashish Ranjan
and compile JCHEVM with GCC. Since you have successfully compiled the
code with GCC, could
you tell/send me the modifications you did, in order for me to speed up
the job?
Has anybody tried to use the U/WIN project by AT&T instead of MinGW?
The U/WIN project is a DLL (posix.dll) that seats on top of Windows and
allows the programmer to call all POSIX APIs
Enrico
Re: [jchevm] Porting JCHEVM to OSX/PPC
Posted by David Tanzer <st...@guglhupf.net>.
The good news first: it compiles now. The problem I described in the
previous mail was that libjc was linked with the option "-module" (so
it can be dlopen()ed) and this is not portable. I removed the -module
and now it compiles.
I stripped out lots of ELF specific stuff, so my version could be
interesting for a port to windows too. I just don't want to commit it
to "trunk" yet because it's completely untested.
@Archie Cobbs: Is the "-module" really important for libjc? If yes we'd
have to find a portable solution for this...
To make it compile I left the funtion "_jc_dynamic_invoke(...)" in the
file "libjc/arc/ppc/arch_functions.c" empty, but this function is needed
to run JCHEVM (it calls C functions and is needed for JNI AFAICS). Maybe
somebody with more PPC experience can help me with porting this function
from i386.
Cheers, David.
On Sat, 2005-11-26 at 11:44 +0100, David Tanzer wrote:
> Hi Again.
>
> Now it compiles, but the linking fails:
>
> Making all in jc
> /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -g -O3 -pipe -Wall
> -Waggregate-return -Wcast-align -Wchar-subscripts -Wcomment -Wformat -
> Wimplicit -Wmissing-declarations -Wmissing-prototypes -Wnested-
> externs -Wno-long-long -Wparentheses -Wpointer-arith -Wredundant-
> decls -Wreturn-type -Wswitch -Wtrigraphs -Wuninitialized -Wunused -
> Wwrite-strings -g -O2 -pthread -o jc main.o ../libjc/libjc.la -ldl -
> lpopt -lcrypto -lz -lm
>
> *** Warning: Linking the executable jc against the loadable module
> *** libjc.so is not portable!
> ** Warning, lib libjc.so is a module, not a shared library
>
> ** And there doesn't seem to be a static archive available
> ** The link will probably fail, sorry
> gcc -g -O2 -g -O3 -pipe -Wall -Waggregate-return -Wcast-align -Wchar-
> subscripts -Wcomment -Wformat -Wimplicit -Wmissing-declarations -
> Wmissing-prototypes -Wnested-externs -Wno-long-long -Wparentheses -
> Wpointer-arith -Wredundant-decls -Wreturn-type -Wswitch -Wtrigraphs -
> Wuninitialized -Wunused -Wwrite-strings -g -O2 -o .libs/jc main.o -
> pthread ../libjc/.libs/libjc.so -L/sw/lib -ldl /sw/lib/libpopt.dylib /
> sw/lib/libintl.dylib /sw/lib/libiconv.dylib -lcrypto -lz -lm
> powerpc-apple-darwin8-gcc-4.0.1: unrecognized option '-pthread'
> /usr/bin/ld: ../libjc/.libs/libjc.so is input for the dynamic link
> editor, is not relocatable by the static link editor again
> collect2: ld returned 1 exit status
> make[1]: *** [jc] Error 1
> make: *** [all-recursive] Error 1
>
> Something similar is discussed here:
> http://www.cocoadev.com/index.pl?ApplicationLinkingIssues
>
> Maybe somebody here on this list knows how to handle this.
> Cheers, David.
>
> On Thu, 2005-11-24 at 17:22 +0100, David Tanzer wrote:
> > Hi Archie,
> >
> > Thanks for your help so far. etc/makedist.sh runs now, and I have
> > removed some more elf specific stuff from libjc/ (I hope I didn't
> > destroy too much ;)). The build now hangs at libjc/gc_root.c where
> > _JC_REGISTER_OFFS is used for the first time. AFAICS this relies on
> > the i386 registers, so I guess this one will become more tricky to
> > port. I'll have a closer look into that over the weekend.
> >
> > Cheers, David.
> >
> > On Wed, 2005-11-23 at 11:56 -0600, Archie Cobbs wrote:
> > > David Tanzer wrote:
> > > > Thanks, your infos brought me a little bit further. Not etc/makedist.sh
> > > > fails when it invokes jcjavah for the first time: the
> > > > _JC_MUTEX_LOCK(...)
> > > > called from libjc/class_bytes.c (line 102) fails because of EINVAL, I'll
> > > > have a look at this in the next few days. Maybe you have some hints for
> > > > me where I could start?
> > >
> > > Oops, fortunately that's an easy fix.. should be fixed now...
> > > svn update and try again.
> > >
> > > -Archie
> > >
> > > __________________________________________________________________________
> > > Archie Cobbs * CTO, Awarix * http://www.awarix.com
--
David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe
http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net
My PGP Public Key: http://guglhupf.net/david/david.asc
--
Real Programmers don't write in FORTRAN. FORTRAN is for pipe stress freaks and
crystallography weenies. FORTRAN is for wimp engineers who wear white socks.
Re: [jchevm] Porting JCHEVM to OSX/PPC
Posted by David Tanzer <st...@guglhupf.net>.
Hi Again.
Now it compiles, but the linking fails:
Making all in jc
/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -g -O3 -pipe -Wall
-Waggregate-return -Wcast-align -Wchar-subscripts -Wcomment -Wformat -
Wimplicit -Wmissing-declarations -Wmissing-prototypes -Wnested-
externs -Wno-long-long -Wparentheses -Wpointer-arith -Wredundant-
decls -Wreturn-type -Wswitch -Wtrigraphs -Wuninitialized -Wunused -
Wwrite-strings -g -O2 -pthread -o jc main.o ../libjc/libjc.la -ldl -
lpopt -lcrypto -lz -lm
*** Warning: Linking the executable jc against the loadable module
*** libjc.so is not portable!
** Warning, lib libjc.so is a module, not a shared library
** And there doesn't seem to be a static archive available
** The link will probably fail, sorry
gcc -g -O2 -g -O3 -pipe -Wall -Waggregate-return -Wcast-align -Wchar-
subscripts -Wcomment -Wformat -Wimplicit -Wmissing-declarations -
Wmissing-prototypes -Wnested-externs -Wno-long-long -Wparentheses -
Wpointer-arith -Wredundant-decls -Wreturn-type -Wswitch -Wtrigraphs -
Wuninitialized -Wunused -Wwrite-strings -g -O2 -o .libs/jc main.o -
pthread ../libjc/.libs/libjc.so -L/sw/lib -ldl /sw/lib/libpopt.dylib /
sw/lib/libintl.dylib /sw/lib/libiconv.dylib -lcrypto -lz -lm
powerpc-apple-darwin8-gcc-4.0.1: unrecognized option '-pthread'
/usr/bin/ld: ../libjc/.libs/libjc.so is input for the dynamic link
editor, is not relocatable by the static link editor again
collect2: ld returned 1 exit status
make[1]: *** [jc] Error 1
make: *** [all-recursive] Error 1
Something similar is discussed here:
http://www.cocoadev.com/index.pl?ApplicationLinkingIssues
Maybe somebody here on this list knows how to handle this.
Cheers, David.
On Thu, 2005-11-24 at 17:22 +0100, David Tanzer wrote:
> Hi Archie,
>
> Thanks for your help so far. etc/makedist.sh runs now, and I have
> removed some more elf specific stuff from libjc/ (I hope I didn't
> destroy too much ;)). The build now hangs at libjc/gc_root.c where
> _JC_REGISTER_OFFS is used for the first time. AFAICS this relies on
> the i386 registers, so I guess this one will become more tricky to
> port. I'll have a closer look into that over the weekend.
>
> Cheers, David.
>
> On Wed, 2005-11-23 at 11:56 -0600, Archie Cobbs wrote:
> > David Tanzer wrote:
> > > Thanks, your infos brought me a little bit further. Not etc/makedist.sh
> > > fails when it invokes jcjavah for the first time: the
> > > _JC_MUTEX_LOCK(...)
> > > called from libjc/class_bytes.c (line 102) fails because of EINVAL, I'll
> > > have a look at this in the next few days. Maybe you have some hints for
> > > me where I could start?
> >
> > Oops, fortunately that's an easy fix.. should be fixed now...
> > svn update and try again.
> >
> > -Archie
> >
> > __________________________________________________________________________
> > Archie Cobbs * CTO, Awarix * http://www.awarix.com
--
David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe
http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net
My PGP Public Key: http://guglhupf.net/david/david.asc
--
Bubba Bo Bob Brain Episode:
Brain: Pinky, Are You Pondering What I'm Pondering?
Pinky: Uh, I think so, Brain, but burlap chafes me so.
Re: [jchevm] Porting JCHEVM to OSX/PPC
Posted by David Tanzer <st...@guglhupf.net>.
Hi Archie,
Thanks for your help so far. etc/makedist.sh runs now, and I have
removed some more elf specific stuff from libjc/ (I hope I didn't
destroy too much ;)). The build now hangs at libjc/gc_root.c where
_JC_REGISTER_OFFS is used for the first time. AFAICS this relies on
the i386 registers, so I guess this one will become more tricky to
port. I'll have a closer look into that over the weekend.
Cheers, David.
On Wed, 2005-11-23 at 11:56 -0600, Archie Cobbs wrote:
> David Tanzer wrote:
> > Thanks, your infos brought me a little bit further. Not etc/makedist.sh
> > fails when it invokes jcjavah for the first time: the
> > _JC_MUTEX_LOCK(...)
> > called from libjc/class_bytes.c (line 102) fails because of EINVAL, I'll
> > have a look at this in the next few days. Maybe you have some hints for
> > me where I could start?
>
> Oops, fortunately that's an easy fix.. should be fixed now...
> svn update and try again.
>
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
--
David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe
http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net
My PGP Public Key: http://guglhupf.net/david/david.asc
--
A debugged program is one for which you have not yet found the conditions
that make it fail.
-- Jerry Ogdin
Re: [jchevm] Porting JCHEVM to OSX/PPC
Posted by Archie Cobbs <ar...@dellroad.org>.
David Tanzer wrote:
> Thanks, your infos brought me a little bit further. Not etc/makedist.sh
> fails when it invokes jcjavah for the first time: the
> _JC_MUTEX_LOCK(...)
> called from libjc/class_bytes.c (line 102) fails because of EINVAL, I'll
> have a look at this in the next few days. Maybe you have some hints for
> me where I could start?
Oops, fortunately that's an easy fix.. should be fixed now...
svn update and try again.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: [jchevm] Porting JCHEVM to OSX/PPC
Posted by David Tanzer <st...@guglhupf.net>.
Thanks, your infos brought me a little bit further. Not etc/makedist.sh
fails when it invokes jcjavah for the first time: the
_JC_MUTEX_LOCK(...)
called from libjc/class_bytes.c (line 102) fails because of EINVAL, I'll
have a look at this in the next few days. Maybe you have some hints for
me where I could start?
Cheers,
David.
On Tue, 2005-11-22 at 14:51 -0600, Archie Cobbs wrote:
> David Tanzer wrote:
> > First of all the problem with the missing "elf.h". Simply copying it
> > from a Linux system doesn't do the job (elf.h has other dependencies,
> > and I didn't want to copy too much headers). Can I remove all the ELF
> > specific stuff? I started doing so, it looks like a lot of work but
> > AFAICS the ELF stuff isn't used anyway in the harmony edition.
>
> You can remove any ELF related stuff, it's not used.
> When time permits I'll work on stripping more stuff out.
>
> > and added the appropriate headers (see next paragraph). Is there a
> > powerpc-port of the original JCVM and could we use it for harmony?
>
> No, x86 is the only port so far.
>
> > In the directory libjc/arch/ppc i added ppc_definitions.h,
> > ppc_structures.h and ppc_libjc.h. I simply copied the files from the
> > i386 directory and used the FreeBSD - Specific stuff where there were OS
> > differences. This doesn't work for "ppc_libjc.h". Here the structure
> > mcontext_t is not defined. Where does that come from on i386?
>
> mcontext_t should be defined by #include <ucontext.h>.
>
> Cheers,
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
--
David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe
http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net
My PGP Public Key: http://guglhupf.net/david/david.asc
--
Pinky, Are You Pondering What I'm Pondering?
Well, I think so Brain but if Jimmy cracks corn and no one cares,
why does he keep doing it?
Re: [jchevm] Porting JCHEVM to OSX/PPC
Posted by Archie Cobbs <ar...@dellroad.org>.
David Tanzer wrote:
> First of all the problem with the missing "elf.h". Simply copying it
> from a Linux system doesn't do the job (elf.h has other dependencies,
> and I didn't want to copy too much headers). Can I remove all the ELF
> specific stuff? I started doing so, it looks like a lot of work but
> AFAICS the ELF stuff isn't used anyway in the harmony edition.
You can remove any ELF related stuff, it's not used.
When time permits I'll work on stripping more stuff out.
> and added the appropriate headers (see next paragraph). Is there a
> powerpc-port of the original JCVM and could we use it for harmony?
No, x86 is the only port so far.
> In the directory libjc/arch/ppc i added ppc_definitions.h,
> ppc_structures.h and ppc_libjc.h. I simply copied the files from the
> i386 directory and used the FreeBSD - Specific stuff where there were OS
> differences. This doesn't work for "ppc_libjc.h". Here the structure
> mcontext_t is not defined. Where does that come from on i386?
mcontext_t should be defined by #include <ucontext.h>.
Cheers,
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com