Posted: Sat Nov 26, 2005 7:45 pm Post subject: Re: The great "invite" from our friends...
pluby wrote:
jjmckenzie51 wrote:
OPENSTEP wrote:
I'd rant, but I don't think I even need to. Who in their right mind would accept an invitation to kill their own project for no upside whatsoever? I'd rather go work on integrating 2.0 into the existing Neo framework so I can finish the bridges and start the NWF (which won't take too long but just isn't as high a need as x86 compatibility).
Let's get to it.
FYI. I just committed some changes to the Neo HEAD branch so that it will try to build using the OpenOffice_2_0_0 branch. Since TeamOOo is using a variety of patches in different branches, this may not be buildable. Nevertheless, it seemed like a good place to start.
Ah, another 'toy' to play with. Patrick you keep on coming up with ideas that keep me busy. With your permission, I will start on building on Tiger and trying to find bugs with it.
pluby wrote:
After I downloaded and built the GNU cp and pkg-config commands from DarwinPorts.org, HEAD is building on my Panther machine and is in the OOo stlport build with gcc 3.3. If anyone is interested in seeing if they can get this to build (and adding the necessary patches to the neojava/patches/openoffice for any necessary fixes), go for it as the HEAD branch is now dedicated to OOo 2.0 building.
Ok. I'm guessing the cvs is cvs checkout -r HEAD NeoOfficeJ
pluby wrote:
jjmckenzie51 wrote:
Again, I think Patrick and you made the best decision with your knowledge.
Thanks for the support. I will admit that there were many times in the Java 1.4.x upgrade that I hit some nasty bug and thought that maybe I should ditch Java and go native. What stopped me has been the one thing that I have learned in my many years of experience: reuse other people's code. In the case of NeoOffice, using Java 1.4.x essentially means that we are reusing the Cocoa code that Apple's JVM engineers wrote. Sure, their code isn't perfect but given that several Apple engineers get paid to write Cocoa fulltime and they have access to the Cocoa engineers within Apple, odds are that their code will in most cases be better than the code that we would have written.
I learnt to program for Windows3.1 from an ex-Microsoft engineer. He stated that it should be ok to reuse code as long as you give credit where credit is due. I still believe in the strategy today. Why rebuild the Brooklyn Bridge when it is there and you can cross it. You may not want to go to Brooklyn but it leads you to JFK airport. That is how I feel. If I use your code but add extensions that you did not want to bother with or could not figure out, then I come along and figure it out and add them and give credit to you, then I feel that this should be ok (in the sprit of Open Source, not using commercial software.)
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sat Nov 26, 2005 9:33 pm Post subject: Re: The great "invite" from our friends...
jjmckenzie51 wrote:
Ok. I'm guessing the cvs is cvs checkout -r HEAD NeoOfficeJ
Slightly OT...
The new module name is just "NeoOffice" IIRC. You still can just grab the neojava module standalone since Patrick set up his CVS work correctly in such a way that doesn't actually need the creepy modules
Posted: Sat Nov 26, 2005 9:42 pm Post subject: Re: The great "invite" from our friends...
OPENSTEP wrote:
jjmckenzie51 wrote:
Ok. I'm guessing the cvs is cvs checkout -r HEAD NeoOfficeJ
Slightly OT...
The new module name is just "NeoOffice" IIRC. You still can just grab the neojava module standalone since Patrick set up his CVS work correctly in such a way that doesn't actually need the creepy modules
Hmmm. Moderating the moderator (sigh.) Ok. Patrick started it and I just followed up on the line of the conversation. As soon as I learn how to move just part of a message. I've got to learn the business of moderating and moving messages again (I was a BBS SysOp and FidoNet message list moderator in a prior life before the Internet.)
And thanks for the update. I tried to get the NeoOffice 1.2 Alpha code with just NeoOffice at the end and ended up with a mess. So, Ed, you say this is fixed or do I have to wave a half baked fish over the keyboard to get only the code and not the mess that went with it? (You have to read the 5th Wave to get the fish part.)
Could you please point out the beginners guide in a PM?
Posted: Sun Nov 27, 2005 12:16 am Post subject: Re: The great "invite" from our friends...
OPENSTEP wrote:
The new module name is just "NeoOffice" IIRC. You still can just grab the neojava module standalone since Patrick set up his CVS work correctly in such a way that doesn't actually need the creepy modules
Both "NeoOffice" and "NeoOfficeJ" will work. I renamed the old "NeoOffice" alias to "NeoOfficeC" after James filed the cvs bug in Bugzilla and recreated "NeoOffice" to be identical to "NeoOfficeJ".
Posted: Sun Nov 27, 2005 12:22 am Post subject: Re: The great "invite" from our friends...
jjmckenzie51 wrote:
Ah, another 'toy' to play with. Patrick you keep on coming up with ideas that keep me busy. With your permission, I will start on building on Tiger and trying to find bugs with it.
Any help that you can provide would be much appreciated as I will probably spend most of the next week trying to fix any Neo 1.2 Alpha bugs that get filed.
BTW, my HEAD build breaks with the following error in the registry module so I expect that your will too:
ld: Undefined symbols:
/usr/bin/libtool: internal link edit command failed
_STL::_Swap_lock_struct<0>::_S_swap_lock
dmake: Error code 1, while making '../unxmacxp.pro/lib/libreg.dylib.3'
'---* tg_merge.mk *---'
Posted: Mon Nov 28, 2005 6:31 pm Post subject: Re: The great "invite" from our friends...
pluby wrote:
jjmckenzie51 wrote:
Ah, another 'toy' to play with. Patrick you keep on coming up with ideas that keep me busy. With your permission, I will start on building on Tiger and trying to find bugs with it.
Any help that you can provide would be much appreciated as I will probably spend most of the next week trying to fix any Neo 1.2 Alpha bugs that get filed.
BTW, my HEAD build breaks with the following error in the registry module so I expect that your will too:
ld: Undefined symbols:
/usr/bin/libtool: internal link edit command failed
_STL::_Swap_lock_struct<0>::_S_swap_lock
dmake: Error code 1, while making '../unxmacxp.pro/lib/libreg.dylib.3'
'---* tg_merge.mk *---'
Nope. but I'm building with gcc4, which is what is supposed to be used with Milestone 142 (which is supposed to build without error) and I get the following while building stlport:
function)
../stlport/stl/debug/_debug.c:270: error: `va_end' undeclared (first use this
function)
make: *** [../lib/obj/GCC/ReleaseD/dll_main.o] Error 1
dmake: Error code 2, while making './unxmacxp.pro/misc/build/so_built_so_stlport'
'---* tg_merge.mk *---'
ERROR: Error 65280 occurred while making /Users/jamesmckenzie/NeoOfficeBuild/OpenOffice_m142/stlport
dmake: Error code 1, while making 'build_instsetoo_native'
'---* tg_merge.mk *---'
Not fun, but I'm going to look that one up as soon as I can at OpenOffice.
Update Found the solution to this one in IZ 49044 (and it is a regression error maybe from a Security update.)
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Mon Nov 28, 2005 11:01 pm Post subject:
Also note that gcc4 really doesn't mean anything for OS X...we need to standardize on a particular subrevision of XCode. The headers have changed ever so slightly for 2.0, 2.1, and 2.2, which makes stlport compilation a nightmare. I've been targeting 2.1 myself, but we should most likely target 2.2 for the best ABI compatibility with x86 os x.
Also note that gcc4 really doesn't mean anything for OS X...we need to standardize on a particular subrevision of XCode. The headers have changed ever so slightly for 2.0, 2.1, and 2.2, which makes stlport compilation a nightmare. I've been targeting 2.1 myself, but we should most likely target 2.2 for the best ABI compatibility with x86 os x.
I agree. The problem I ran into was regressed and was corrected in XCode 2.1. It has to do wit the placement of stdargs.h. This would definately cause errors in building NeoOffice 2.0 and was fixed for XCode 2.1 a long time ago and was proven in a build of Milestone 131/133 that I did.
I agree. The problem I ran into was regressed and was corrected in XCode 2.1. It has to do wit the placement of stdargs.h. This would definately cause errors in building NeoOffice 2.0 and was fixed for XCode 2.1 a long time ago and was proven in a build of Milestone 131/133 that I did.
Interesting. I had applied Ed's stdargs.h patch (the one that my OOo 1.1.5 build uses) and there was no change. I'll have to fuss with this when I have time.
BTW, the problem that I am going to have is that I will need to continue to build using gcc 3.3 since I will need to build and release binaries that work on Panther and higher on the PowerPC platform. Things are easier on the Mactel platform since there is no Panther release but I think we cannot escape gcc 3.3 for Panther.
I agree. The problem I ran into was regressed and was corrected in XCode 2.1. It has to do wit the placement of stdargs.h. This would definately cause errors in building NeoOffice 2.0 and was fixed for XCode 2.1 a long time ago and was proven in a build of Milestone 131/133 that I did.
Interesting. I had applied Ed's stdargs.h patch (the one that my OOo 1.1.5 build uses) and there was no change. I'll have to fuss with this when I have time.
The build continues. I'm in sw and hope it completes. After this, I will work on a gcc-3.3 build. Maybe all I needed was the stlport patch.
pluby wrote:
BTW, the problem that I am going to have is that I will need to continue to build using gcc 3.3 since I will need to build and release binaries that work on Panther and higher on the PowerPC platform. Things are easier on the Mactel platform since there is no Panther release but I think we cannot escape gcc 3.3 for Panther.
True. As I stated, I will try a gcc-3.3 build. I'm hoping that this build will finish this evening or at least before tomorrow morning.
The build continues. I'm in sw and hope it completes. After this, I will work on a gcc-3.3 build. Maybe all I needed was the stlport patch.
Is there a URL for this patch? If so, I can try it out.
Patrick:
It is on the OpenOffice.org site. It is IZ 49044 and is a patch to the macosx patch for STLport 4.5. There is a series of patches. I would check the makefile.mk file for stlport and make sure that the stlport-4.5-macosx.patch is being applied. BTW, which version of OpenOffice 2.0 are you trying to build?
BTW, which version of OpenOffice 2.0 are you trying to build?
The makefile builds the OpenOffice_2_0_0 tag which, I believe, is the official tag used for the Windows, Linux, and Solaris OOo 2.0 release. I know that the OOo Mac team is probably using a child branch, but since there are several child branches and patches floating around, I thought it might be much simpler in the long run (but not in the short run), to check in all of the patches to the mainline OOo releases that necessary to build. That way, when OOo jumps to OOo 2.0.1, 2.0.2, etc. we will be able to easily carry the patches.
BTW, which version of OpenOffice 2.0 are you trying to build?
The makefile builds the OpenOffice_2_0_0 tag which, I believe, is the official tag used for the Windows, Linux, and Solaris OOo 2.0 release. I know that the OOo Mac team is probably using a child branch, but since there are several child branches and patches floating around, I thought it might be much simpler in the long run (but not in the short run), to check in all of the patches to the mainline OOo releases that necessary to build. That way, when OOo jumps to OOo 2.0.1, 2.0.2, etc. we will be able to easily carry the patches.
I think the MacOSX line is in ooo680_m(xx) and this is then merged back into the main branch. The build is finished and functionally tested. Now to start building with gcc-3.3 and see if it breaks in the stlport module/project.
C O R R E C T I O N I built the gcc-3-3 version and am now working on the gcc-4.0 version. If this completes building past stlport, then I will get the OpenOffice_2_0_0 code and a fresh pull of SRC680_m142 and try to figure out what happened. I'm guessing there are patches missing from this code and it will not build without them on MacOSX/gcc-3.3/Java 1.4.2.
/ C O R R E C T I O N
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Dec 01, 2005 9:52 am Post subject:
Just a general note: I'm still relaxing with my family through the weekend (now I have my entire family here with me visiting!) but I'll begin jumping in again to help next week. Here's hoping the x86 machines don't go on sale in January like is rumored...
Patrick: I'm assuming that, for now, all of the patches against the OOo code haven't been updated. If James is working on examining the build support, it might be best for me to start seeing what patches got incorporated and which didn't. Since the patches were pretty much ignored by Eric & co., I suspect they haven't filtered into the main tree.
All times are GMT - 7 Hours Goto page 1, 2, 3 ... 14, 15, 16Next
Page 1 of 16
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
