I'm just wondering if anyone has tried compiling openoffice from source on the amd64 platform. I've seen discussions on bugs.gentoo.org regarding how best to get openoffice-bin to work (generally involving telling it to install without using sandbox), but the site is conspicuously quiet regarding the full compile....any comments or things to be aware of before I tweak the ebuild and think good thoughts?

Since this is the branch that I gather is to be OO2.0, I suspect it's not going to appear anytime soon, also from what I can tell, x86_64 porting is not being driven hard, although it's hard to know other that what can be found on google or in the OO bug tracking database. Seems there is a lack of machines to build and test on.

Well, I finally decided to keep the computer busy so that I could study without distraction, only to find that the openoffice ebuild in portage is not intended for amd64 use. When I tried a compile, it died in the first stages of configuration.

Also, it seems that the developers are updating their lists of "what software *won't work*" at http://amd64.gentoo.org It seems that this is the outgrowth of Brad's tech notes, and it's highly useful. This may already be common knowledge, but I wasn't aware of it....

Well if you want to start working on getting it to compile you can start here, look in that file and on all those lines it will start with something like pushl $255, %rax or something similar, just change all the pushl or popl or compl or whatever to pushq, popq, copq or whatever it is and that will fix those problems.
Although i am sure you don't want to wade through the millions of lines of code doing that, then recompiling, then fixing the next thing etc, but i am sure the openoffice team will get around to it sometime, it just depends on how long we want to wait.

Unfortunately, if everyone has that attitude, the developer base is going to get really small. My philosophy is that if you want something done, you should learn to do it yourself. That's basically what this OS is all about. I know I'm gonna try to get some of my ideas implemented. I think I've mentioned it before, but I'll mention it again: it seems to me that what we need is a 64/32 bit hybrid kernel that can make use of the 32-bit packages already in existence. My thoughts are that the hardware abstractions of system calls should insulate us from having to do much work if we can just get a 64-bit kernel to run 32-bit modules. This, of course, is a problem if there isn't a way to switch the 64-bit Athlon64 into 32-bit mode on the fly , but I seem to recall that there's a way to do this. I'll be looking into it.

Unfortunately, if everyone has that attitude, the developer base is going to get really small.

I usually try to stay away from trolls but just to clarify the attitude i had.

Quote:

Well if you want to start working on getting it to compile you can start here,

Ok so i started off by addressing the problem that they were facing and giving a start of how to start looking

Quote:

Although i am sure you don't want to wade through the millions of lines of code doing that

Then i acknoledged the fact that OO.org is a HUGH code base and will take a lot of work to port over which many individuals don't have time for (read i don't have time for)

Quote:

but i am sure the openoffice team will get around to it sometime

So some day it probably will get ported over

Quote:

it just depends on how long we want to wait.

But if you (we... anyone) want to get it ported more quickly then you will have to go through the millions of lines of code and put the effort in yourself.

I'm sorry i was unclear on my _attitude_ in my original post. Let me rephrase what i was trying to say to be more clear. If you want to get OO.org to run natively on x86_64 then it will take some serious effort and a place to start is the post up above, if you don't want to do the work yourself then chances are it will get done by someone else eventually but if you want it done now then do it.

Sorry to everyone for responding to a troll but i promise it won't happen again, i'll stop watching this thread so i'm not even baited.

Well, I'm toying with it, and will continue to plod along, but my assembler days are from the 80s, and I am a crude hack when it comes to C, and the problem appears to be the inline assembly code, I've been hunting around for similar code that may be working... no luck yet.

OO is a big fat project, and a lot to digest, I've grabbed a copy from CVS, if more of you want to play with it, I'd be glad to post every thing I know so far, and what bit's of resources I've found in my quest to get a x86_64 build of OO.

But if you (we... anyone) want to get it ported more quickly then you will have to go through the millions of lines of code and put the effort in yourself.

Actually you don't have to go through it all, so far I've found a few issues, and not a lot of actual code browsing, although it could get that way.. Anyway, the port to x86_64 is taking place, so the biggest issues are going to be finding build stoppers, and if noone builds it, it will take longer for them (the OO folks) to find and fix the serious problems, as I don't see much evidence of x86_64 building going on.

I have yet to attempt to get that to work (recently anyhow, I
tried a long time ago, but didn't have any time to dedicate to
it).

If anyone successfully builds it, let me know. Also, let me know the
full details of what you did, I'd like to get an ebuild up for OOo2
on amd64 if possible, I just don't have time to dedicate to it right
now (in actuality, I don't use my amd64 as a desktop, so I don't have
a personal need for it, otherwise, I'd probably already have it working).

Well if you want to start working on getting it to compile you can start here, look in that file and on all those lines it will start with something like pushl $255, %rax or something similar, just change all the pushl or popl or compl or whatever to pushq, popq, copq or whatever it is and that will fix those problems.
Although i am sure you don't want to wade through the millions of lines of code doing that, then recompiling, then fixing the next thing etc, but i am sure the openoffice team will get around to it sometime, it just depends on how long we want to wait.

-Chris

Instead of Trying to fix all these assembler issues. I think it might just be picking up the wrong JDK/JRE to compile, because blackdown has released an AMD64 version, which makes me think this has been fixed.