gcc4 porting

OPENSTEP · Posted: Wed Sep 07, 2005 10:51 pm Post subject: gcc4 porting

OK, so now that CVS is done and I've finally come to the conclusion no one seems to have been taking the approach I was of defining a "USE_GCC4" for the OOo build system (damn you collabnet...where is a plain old CVSWeb so I can view "poor man" visual diffs!!) I think I have gotten onto the approach that others are using for gcc4 on the OOo 2.0/64 bit branches:

- define USE_GCC3 for the makefiles
- leave the makefile CVER at 300 (aargh!)
- insert casts as appropriate, if not harmful for earlier gccs, no ifdef guard
- rely on the (__GNUC__ > 4) macro for any gcc4 specific guards

Thus far I've patched config_office and stlport, but the patches are not yet committed. I'm debating whether I should commit them to HEAD or make a branch for the gcc4 stuff. It affects the underlying OOo compile, obviously, so it makes more sense to branch them to me...

In the meantime, whee! gcc4 header compile errors! Bleh. The next one just came up. Back to work for me.

ed

OPENSTEP · Posted: Wed Sep 07, 2005 11:01 pm Post subject:

Next module, soltools. st_list.hxx: apparently derived templates seem to have difficulty accessing protected data members indirectly in gcc4 but this was cool in gcc3. Access to protected members of superclass templates must be fully qualified with the subclass template name in template member function definitions.

ed

OPENSTEP · Posted: Wed Sep 07, 2005 11:09 pm Post subject:

Suffering from that same protected access problem, list templates in xml2cmp. Another module that needs a patch.

Need I say proper data accessors/object encapsulation design would have never exposed these errors? Very Happy

ed

jjmckenzie51 · Posted: Thu Sep 08, 2005 1:08 pm Post subject:

OPENSTEP · Posted: Fri Sep 09, 2005 6:34 pm Post subject:

Yup. A lot of the gcc4 fixes have been applied to the 64 bit OOo 2.0 branch and some to the mainline. Since I'm back in the 1.1.4 code chances are that I'll be encountering a lot that don't apply for newer codebases.

ed

OPENSTEP · Posted: Sat Sep 10, 2005 11:50 am Post subject:

Next module that needs patching in base OOo build: sal. I'm keeping track of these here so I don't forget which patches I need to regenerate for the neoj build Smile

For anyone unawares, gcc4 compilation support is one of the major things needed for Mactel compilation support. gcc3 does not support Mactel codegen on the development machines. This is really a half-truth, however, as I have been able to successfully patch the gcc source code for 3.4 to build on Mactel as I needed g77...but it seems a bit absurd to not use the Apple compilers in place of some custom ed hackjob.

ed

pluby · The Architect Joined: Jun 16, 2003 Posts: 11949

Ed,

Do you think it would be easier to use gcc4 with the OOo 2.0 codebase? If so, I can shuffle the development priorities to put the OOo 2.0 upgrade immediately after the Java 1.4 work is done.

Patrick

OPENSTEP · Posted: Sun Sep 11, 2005 11:36 am Post subject:

It may be a bit easier to do it off of the 2.0 codebase, but I suspect that there will just be other difficulties in there. I don't know what's used for the official builds on other platforms, but I suspect that most of them are still done off of gcc3.3. Not all of the fixes I've seen are on the branches. In general, it's not been that bad...more just run the compiler, find the error, fix it, and move on.

The Java 1.4 stuff should definitely be the highest priority, however, as it's the keystone for x86 work. I'll of course do the gcc4 stuff when we move to 2.0 as well, but I suspect that it won't be that bad as the configure stuff should go over no problem along with any ABI work. I don't think I need to do any for PowerPC, but I'll need to check to make sure.

ed

OPENSTEP · Posted: Sun Sep 11, 2005 12:48 pm Post subject:

Durn. The ABI did change...but hopefully the calling conventions and the like didn't change requiring new PPC c++ glue:

http://developer.apple.com/releasenotes/DeveloperTools/GCC4.html

There's also a fair overview of the template parsing changes that are resulting in the compile and link errors.

Next module that needed patching was the storage module. Templates in gcc4 no longer implicitly instantiate template member functions based on their parameters...an explicit <typename foo> is required.

ed

OPENSTEP · Posted: Sun Sep 11, 2005 1:09 pm Post subject:

Next module: python. Why OOo has an embedded copy of python I don't know, especially as python ships with OS X. Regardless, its build system needs to be updated to have proper linker flags for libtool generating dynamic libs.

Note that I am still in the OOo code, not in our own code yet Smile

ed

OPENSTEP · Posted: Sun Sep 11, 2005 5:35 pm Post subject:

autodoc also requires a patch. Just keeping track for when i have to create the patchfiles in the future.

ed

OPENSTEP · Posted: Sun Sep 11, 2005 5:54 pm Post subject:

icu requires patching. Note as this is a third-party library, it requires generation of a new patchfile for the external code. There was no difference in HEAD for the stock patchfile.

ed

OPENSTEP · Posted: Sun Sep 11, 2005 6:13 pm Post subject:

Well, idlc segfaults when processing udkapi. Sound familiar? Smile

I've heard that folks have gotten 2.0 code to compile with gcc4, but an idlc crash makes me think there may still be lurking issues.

ed

sardisson · Town Crier Joined: Feb 01, 2004 Posts: 4588

pluby · The Architect Joined: Jun 16, 2003 Posts: 11949

Ed,

If it makes life easier, you can just create a new branch for your gcc4 work. Since we are both working with the OOo 1.1.4 code and I am only making changes to vcl at this point, I think that you could save yourself some hassle by creating a gcc4_experimental_branch (or something like that) off of HEAD and then you can just commit your "cvs diff -u <module>" into the patches/openoffice directory.

Don't worry about changing the makefile, just create the branch to save your patches.

Patrick