Posted: Tue Dec 27, 2005 1:32 pm Post subject: Re: Neo 2.0 building...
pluby wrote:
Using 2_0_1 is almost guaranteed not to work. The Neo build works by patching the OOo code both before and after the OOo build so swapping in a different OOo tag is very likely to cause application of 2_0_0 patches to 2_0_1 code.
Since 2_0_0 builds on both Panther and Tiger for me, my first priority is to finish moving the NeoOffice custom vcl and installer code to match the OOo 2_0_0 branch. Only after I get that done will I worry about upgrading the build to use the newest OOo tag. After all, if it takes two months for me to get that done, OOo 2_0_2 could be out by then so waste time on continually upgrading the build.
Patrick
That's very fine reasoning. However, when I was trying to build with OOo 2_0_0 tag and latest Neo HEAD, the OOo build did FAIL, like I reported about it previously in this thread.
With OOo 2.0.1, I have had more luck. It has not finished yet, but I have built 124 of 177 OOo modules.
I have had two build failures so far, that I succeeded to fix:
Code:
The stlport -module failed with a problem that it could not find stdarg.h, even though it does exist in standard system location. Bybassed this problem by using compiled stlport from the oo200 build.
Code:
FAILED in sj2/util with:
ld: Undefined symbols: _XSync
/usr/bin/libtool: internal link edit command failed
dmake: Error code 1, while making '../unxmacxp.pro/lib/libj680mxp_g.dylib'
---> FIXED (manually):
added "-lX11" to "sj2/unxmacxp.pro/misc/libj680mxp_g.cmd"
and then ran it manually: "cd sj2/unxmacxp.pro/misc/; source libj680mxp_g.cmd"
Posted: Tue Dec 27, 2005 3:03 pm Post subject: Re: Neo 2.0 building...
Mox wrote:
That's very fine reasoning. However, when I was trying to build with OOo 2_0_0 tag and latest Neo HEAD, the OOo build did FAIL, like I reported about it previously in this thread.With OOo 2.0.1, I have had more luck. It has not finished yet, but I have built 124 of 177 OOo modules.
I just looked at your errors and it seems to me that you probably have a custom PATH and DYLD_LIBRARY_PATH settings that have directories in your Fink installation (i.e. /sw). I build with a very clean environment with PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/opt/local/bin and DYLD_LIBRARY_PATH not set.
What most people don't realize is that anything in DYLD_LIBRARY_PATH will be searched before the system library directories. So, if you have libiconv.dylib in your Fink installation and Fink is in your DYLD_LIBRARY_PATH variable, the Mac OS X linker will try to link against your Fink libiconv.dylib instead of /usr/lib/libiconv.dylib.
You may want to try checking out the NeoOffice code tomorrow (after tonight's cvs sync) and unsetting your DYLD_LIBRARY_PATH and excluding Fink from your PATH before starting the build.
Mox wrote:
I have had two build failures so far, that I succeeded to fix:
Code:
The stlport -module failed with a problem that it could not find stdarg.h, even though it does exist in standard system location. Bybassed this problem by using compiled stlport from the oo200 build.
Code:
FAILED in sj2/util with:
ld: Undefined symbols: _XSync
/usr/bin/libtool: internal link edit command failed
dmake: Error code 1, while making '../unxmacxp.pro/lib/libj680mxp_g.dylib'
---> FIXED (manually):
added "-lX11" to "sj2/unxmacxp.pro/misc/libj680mxp_g.cmd"
and then ran it manually: "cd sj2/unxmacxp.pro/misc/; source libj680mxp_g.cmd"
So, basically, by using a different OOo tag and changing nearly a dozen configure options, you are really building something quite different from what the NeoOffice makefile and README.txt expects. That is not as a problem in and of itself, but I can't really offer any advice as to where your problems are occurring as I was able to build without changing the NeoOffice makefile using the README.txt instructions on both Panther and Tiger.
I do know that the two errors you mentioned are caused by code changes between OOo 2.0 and 2.0.1. When I did a simple cvs diff in these modules, I found that the Mac OS X stlport fixes in OOo 2.0 got stripped out of the 2.0.1 files and I found that in sj2 the XSync calls were added in OOo 2.0.1.
I have committed patches in the neojava/patches/openoffice directory for these and I have modified the makefile to checkout the OpenOffice_2_0_1 tag. I am doing a clean checkout of the NeoOffice source code and starting a build to see how far mine gets.
Edit: I have committed a change to the makefile that will temporarily unset your DYLD_LIBRARY_PATH and set your PATH
to the default system path while OOo's configure script is run. This should prevent the OOo build from trying to link to Fink's custom libraries instead of the system libraries.
FYI. My Neo build using the OOo 2.0.1 build crapped out last night due to a build error in the sj2 module. I have fixed this by updating the neojava/patches/openoffice/sj2.patch file. So, if you are running a build that you checked out this morning, kill your build, do a "cvs update -d" in the "neojava" directory, and invoke "make" to start your build again. Restarting the build will cause my updated sj2 patch to be applied.
FYI. My Neo build using the OOo 2.0.1 build crapped out last night due to a build error in the sj2 module. I have fixed this by updating the neojava/patches/openoffice/sj2.patch file. So, if you are running a build that you checked out this morning, kill your build, do a "cvs update -d" in the "neojava" directory, and invoke "make" to start your build again. Restarting the build will cause my updated sj2 patch to be applied.
As I stated elsewhere, I'm going to hold off on pulling down the CVS. Thanks for the update.
Posted: Thu Dec 29, 2005 5:37 am Post subject: Compiling OOo 2.0.1
pluby wrote:
FYI. My Neo build using the OOo 2.0.1 build crapped out last night due to a build error in the sj2 module. I have fixed this by updating the neojava/patches/openoffice/sj2.patch file. So, if you are running a build that you checked out this morning, kill your build, do a "cvs update -d" in the "neojava" directory, and invoke "make" to start your build again. Restarting the build will cause my updated sj2 patch to be applied.
Patrick
Yes, I got hit by that one. Updated from the cvs and building again... Yesterday, when I was building with Xcode 2.1 and (probably unpatched) sj2, I got until instsetoo_native.
There the build failed in registering pyuno_services.rdb. This problem is probably indirectly caused by using --with-system-python. I may have a fix for it though... Trying to rebuild.
Late yesterday I installed XCode 2.2, and started with a clean OOo 2.0.1, Neo HEAD and gcc 3.3. Got hit by the sj2 thing, but it now works, after updating Neo CVS again. Building continues...
I tried to use gcc 4.0.x also, but it failed on stlport
.....
I know that I'm using more --with-system-<stuff> than you are. The OOo is so huge codebase that I prefer to use as much system stuff as possible, so that rebuilds are quicker. It takes at least a full day to build and you have to constantly check that the build is not failing on something.
Besides, with those --with-system-<stuff>, you have less modules to worry about, when thinking about different OSX releases and architectures... The worries are on Apple / Fink / Darwinports
Similarly to what Pavel is planning to do on OOo side, I'd recommend at least using system versions of curl, python and libxml, because these come installed with Mac OS X -- everybody has them! They should also work both in Panther and Tiger. (although, python may need a patch, as I explained earlier).
Finally... Could you please make a small change to the neojava/makefile ? Instead of hardcoding cc and c++, use these CC="$(CC)" CXX="$(CXX)" in the configure -line. Then define CC=cc and CXX=c++ in the start of the makefile, similarly to pkg-config.
With that change, I can easily use ccache -- i.e. "compiler cache" that speeds up recompilations quite nicely and without causing additional bugs.
Thats all so far...
Oh, btw, how many of those openoffice patches that are applied before build are Neo specific? I'm just wondering whether (with your permission, of course) it would be useful to send that stuff upstream...
The X11 removal things are not probably relevant, unless the OOo people are interested in fixing stuff for the eventual and "longhornish" Cocoa/Carbon port... Actually, with "$(OS)"=="MACOSX", should the "$(GUI)"=="UNX" be something else ? (i.e. does that UNX imply X11?). The NOT-X11 OOo -people might be interested in creating defines that would help Neo as well...
Posted: Thu Dec 29, 2005 8:17 am Post subject: Re: Compiling OOo 2.0.1
Mox wrote:
Late yesterday I installed XCode 2.2, and started with a clean OOo 2.0.1, Neo HEAD and gcc 3.3. Got hit by the sj2 thing, but it now works, after updating Neo CVS again. Building continues...
What is your gcc -version line response. I get gcc 3.3 20030304 (build 1819) which is very old for gcc 3.3.
Mox wrote:
I tried to use gcc 4.0.x also, but it failed on stlport
This should be fixed by now in the OOo code. Will have to look into this.
Mox wrote:
I know that I'm using more --with-system-<stuff>
I'm with you here. If the basic operating system comes with the product, use it. EPM is a good example of this. I think that MacOSX comes with this and there should be no need to waste build time rebuilding something.
Mox wrote:
Finally... Could you please make a small change to the neojava/makefile ? Instead of hardcoding cc and c++, use these CC="$(CC)" CXX="$(CXX)" in the configure -line. Then define CC=cc and CXX=c++ in the start of the makefile, similarly to pkg-config.
With that change, I can easily use ccache -- i.e. "compiler cache" that speeds up recompilations quite nicely and without causing additional bugs.
This product makes a huge difference with a slower machine or one that is memory constrained. I use it with Pavel's build product and it cuts about four hours off of the build time with a PBG4 1.3 GHz machine.
Posted: Thu Dec 29, 2005 9:01 am Post subject: Re: Compiling OOo 2.0.1
Mox wrote:
I tried to use gcc 4.0.x also, but it failed on stlport
Did this fail with the latest Neo code i.e. with my stlport.patch file?
Mox wrote:
I know that I'm using more --with-system-<stuff> than you are. The OOo is so huge codebase that I prefer to use as much system stuff as possible, so that rebuilds are quicker. It takes at least a full day to build and you have to constantly check that the build is not failing on something.
No kidding. On my G4 450 MHz development machine it takes more than 2 full days. The good news is that once we can get Neo to reliably build OOo 2.0.1, then rebuilding of OOo won't need to happen for quite a while. I designed Neo's build system so that once I got OOo to build, I could fuss with the custom vcl code and generate a patch installer to test it without having to touch my OOo build.
Mox wrote:
Besides, with those --with-system-<stuff>, you have less modules to worry about, when thinking about different OSX releases and architectures... The worries are on Apple / Fink / Darwinports
Similarly to what Pavel is planning to do on OOo side, I'd recommend at least using system versions of curl, python and libxml, because these come installed with Mac OS X -- everybody has them! They should also work both in Panther and Tiger. (although, python may need a patch, as I explained earlier).
OK. This makes sense and I will add these 3 --with-system-<stuff>. Are there others that should be included? While OOo may have trouble with Fink etc., I do know that Neo should, in the end, only see the system default binaries as the Neo code cleans up the PATH and DYLD_LIBRARY_PATH environment variables to fix bug 1198.
Mox wrote:
Finally... Could you please make a small change to the neojava/makefile ? Instead of hardcoding cc and c++, use these CC="$(CC)" CXX="$(CXX)" in the configure -line. Then define CC=cc and CXX=c++ in the start of the makefile, similarly to pkg-config.Oh, btw, how many of those openoffice patches that are applied before build are Neo specific? I'm just wondering whether (with your permission, of course) it would be useful to send that stuff upstream...
Sure. I will do it today.
Mox wrote:
The X11 removal things are not probably relevant, unless the OOo people are interested in fixing stuff for the eventual and "longhornish" Cocoa/Carbon port... Actually, with "$(OS)"=="MACOSX", should the "$(GUI)"=="UNX" be something else ? (i.e. does that UNX imply X11?). The NOT-X11 OOo -people might be interested in creating defines that would help Neo as well..
I don't know if they would want it or not. But I can always donate the code to OOo at some point and then they can decide whether or not they want to integrate it into their latest builds. However, I do want to make sure that the code actually works first.
Just to let you know that the checkout of the OpenOffice files failed (again) with an error code of 1. I don't know why this is happening, but I opened a fresh terminal window and did an unset CVSROOT to make sure that this variable was not set. I dragged the Mac to 'work' and set it up in the corner with my cellular phone and am grabbing the OpenOffice code again to see what happens.
Just to let you know that the checkout of the OpenOffice files failed (again) with an error code of 1. I don't know why this is happening, but I opened a fresh terminal window and did an unset CVSROOT to make sure that this variable was not set. I dragged the Mac to 'work' and set it up in the corner with my cellular phone and am grabbing the OpenOffice code again to see what happens.
That happened to me once as well. IIRC, the "chmod -Rf u+w" command immediately after checkout silently fails or cvs is returning a non-zero error code but I do not know why. When I reran it the second time (i.e. cvs only updates missing files), I could not repeat the error.
Just to let you know that the checkout of the OpenOffice files failed (again) with an error code of 1. I don't know why this is happening, but I opened a fresh terminal window and did an unset CVSROOT to make sure that this variable was not set. I dragged the Mac to 'work' and set it up in the corner with my cellular phone and am grabbing the OpenOffice code again to see what happens.
That happened to me once as well. IIRC, the "chmod -Rf u+w" command immediately after checkout silently fails or cvs is returning a non-zero error code but I do not know why. When I reran it the second time (i.e. cvs only updates missing files), I could not repeat the error.
One additional note: I ran man cvs and the help it gave is worthless. That is why I've run the checkout by itself and it seems to run without a problem. Maybe I should invoke a script to see if the problem is with the script itself or with the shell I'm using. I think that you invoke cvs in the current shell and only use tcsh for the OO 'stuff' like configure, bootstrap and build.
Posted: Thu Dec 29, 2005 12:50 pm Post subject: Re: Compiling OOo 2.0.1
jjmckenzie51: Don't bother with CVS:ing the oo.o... As long as you are using release builds, just get the tar file from OOo mirrors. For example, OOo 2.0.1 is in http://public.planetmirror.com/pub/openoffice/stable/2.0.1/OOo_2.0.1_src.tar.gz
Unpack that with "tar xvzf OOo_2.0.1_src.tar.gz" in some temporary directory, then move all the directories inside "OOA680_m1/" directory to neojava/build/ directory.
After that, do "touch neojava/build.oo_checkout" and you can forget OOo cvs:ing
and.. my gcc 3.3 is exactly the same as yours. XCode update to 2.2 did not change it... gcc 4.0.x has changed though.
pluby wrote:
Mox wrote:
I tried to use gcc 4.0.x also, but it failed on stlport
Did this fail with the latest Neo code i.e. with my stlport.patch file?
Yes, but I have to check this again... I'll report later, now I'm using gcc 3.3...
pluby wrote:
Mox wrote:
Besides, with those --with-system-<stuff>, you have less modules to worry about, when thinking about different OSX releases and architectures... The worries are on Apple / Fink / Darwinports
Similarly to what Pavel is planning to do on OOo side, I'd recommend at least using system versions of curl, python and libxml, because these come installed with Mac OS X -- everybody has them! They should also work both in Panther and Tiger. (although, python may need a patch, as I explained earlier).
OK. This makes sense and I will add these 3 --with-system-<stuff>. Are there others that should be included? While OOo may have trouble with Fink etc., I do know that Neo should, in the end, only see the system default binaries as the Neo code cleans up the PATH and DYLD_LIBRARY_PATH environment variables to fix bug 1198.
I think other system-things than these three are not found in all the tiger/panther machines
you may need a patch for python in IssueZilla #53280, to get it past instsetoo_native... I haven't verified it though. Found also some other nice, but lurking patches from fink-ooo patch...
I have committed the CC and CXX macro changes to neojava/makefile and I have added --with-system-curl and --with-system-python to the configure script arguments. I didn't add --with-system-libxml because the libxml version on Panther doesn't pass the configure script's requirements.
I have also committed the last stlport patch from OOo IssueZilla 49044 in the neojava/patches/openoffice/stlport.patch file and I have verified that it will build with gcc 4 on Tiger (my build is in offapi right now).
My changes will be available in anoncvs at 3:00 am tonight Pacific time.
Posted: Thu Dec 29, 2005 1:18 pm Post subject: Re: Compiling OOo 2.0.1
Mox wrote:
pluby wrote:
Mox wrote:
I tried to use gcc 4.0.x also, but it failed on stlport
Did this fail with the latest Neo code i.e. with my stlport.patch file?
Yes, but I have to check this again... I'll report later, now I'm using gcc 3.3...
Ok verified that vanilla OOo 2.0.1 source builds stlport just fine with gcc 4.0.1 (XCode 2.2). Your earlier patch, Patrick, breaks it... I will try again tomorrow or later with your updated patch...
.....
Also, Pavel says that the real problem with python might be this:
Quote:
> > error (RuntimeException): python-loader:exceptions.ImportError: No module
> > named pyuno
>
> I think the above error is a problem with using --with-system-python.
Yes. The problem is simple and I have described it in earlier mails. In
short: python is looking for pyuno.so, but we have only pyuno.dylib. I'll fix it soon.
Last edited by Mox on Thu Dec 29, 2005 1:54 pm; edited 1 time in total
Posted: Thu Dec 29, 2005 1:50 pm Post subject: Re: Compiling OOo 2.0.1
Mox wrote:
Ok verified that vanilla OOo 2.0.1 source builds stlport just fine with gcc 4.0.1 (XCode 2.2). Your patch, Patrick, breaks it...
That is true. You won't see the corrected patch until 3:00 am Pacific time tonight as anoncvs is only updated once each day from the main cvs server. Tomorrow, the stlport.patch file will be basically the same as Pavel's last attachment in Issuezilla 49044.
Posted: Thu Dec 29, 2005 3:40 pm Post subject: Re: Compiling OOo 2.0.1
pluby wrote:
That is true. You won't see the corrected patch until 3:00 am Pacific time tonight as anoncvs is only updated once each day from the main cvs server. Tomorrow, the stlport.patch file will be basically the same as Pavel's last attachment in Issuezilla 49044.
Can James and Mox somehow get read access to the main CVS server? The update lag seems to be causing tons of confusion and delays. It would be nice to facilitate their efforts more.
Best wishes,
Oscar _________________ "What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
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
