Created attachment 2715 [details]
patch for stlport 4.5

Created attachment 2716 [details]
unpolished patch - works but may include bugs

Created attachment 2727 [details]
makes the connectivity compile correctly and svx work after that.

approval_pending keyword set.

Sander, can you test these patches on your linux build? 

(cc-ed sander)

Patches are required to 
svx/source/accessibility/ChildrenManagerImpl.cxx in order to get it
too compile,  here is the response from the mail list.

I'd guess those two lines should read

  OSL_TRACE("accessible shape %p not visible", I->get());

and

  OSL_TRACE("shape %p not visible", xShape->get());

respectively.  (Note to use %p for pointers instead of %x).

-Stephan

Created attachment 2915 [details]
note the change to exclude rtti for gcc 3.2

Created attachment 2916 [details]
patch on patch to handle gcc 3.1 and gcc 3.2 compiles.

Note taht for the STLport patch just given that there may be problem
with some vendors including the patch number in the libraries.  Remove
the '//' lines in patch for the setting the version id if this is the
case for your platform.

Update the following to -r 1.24:

svx/source/accessibility/ChildrenManagerImpl.cxx

Created attachment 2958 [details]
patch for gcc 3.2.1 and make error happen when not set up

I have applied the stlport patches,  the tg_compv.mk patches.
The product patches have been made redundant.

This leaves the connectivity patches and svx problem outstanding.

connectivity is not directly related to gcc 3.2.  I dont understand
why others manage to build without this patch.

svx the modified version I was given will not compile without a major
movement of all code.

Created attachment 3091 [details]
Patch to set correct include paths for gcc >= 3.1.1 (diffed against OO642C)

Created attachment 3092 [details]
This is the patch to apply to head to correct for gcc 3.2 and configure changes.

I tried to apply these patches for a gcc-3.2 build (SRX644) based
(stlport-4.5) and all I get are some broken command when executing
make -f gcc-3.mak

Created attachment 3318 [details]
error output

This is caused because you do not have environment variables set to
CC=gcc and CXX=g++. Check you .set file contains these.

The other half of the settings come from the solenv/inc and the
patches that I have applied were not set to the correct tag.  WIll
look at this.

thank you for the hint, although I set CC and CXX to g?? -V 3.2 before
it  was reset by the settings.mk, thanks.

revision 1.123.2.1
date: 2002/09/27 12:51:11;  author: waratah;  state: Exp;  lines: +5 -5
3660: Convert the environment varaibles from CC to CXX and cc to CC,
this compiles with GNU standards
IMplement a process where LINUX compilers come though from configure,
other platforms will follow
Include comments for fixes for gcc 3.2 in unxlngi4.mk

Hi, 
 
What's the status of getting some of these in the tree? 
 
Chris Hall's stlport453-gcc32includes.patch would be a big help 
to buildability (I will backport it to STLport-4.5 and test it on 
OO643C today. 
 
Also the unxlngi4.mk.patch should go into unxlngppc4.mk as well. 
 
If I test these today (and they works) on OO643C may I have approval 
to commit them to that tree. 
 
Thanks, 
 
Kevin 
 

 Hi, 
 
BTW, this part of Chris's patch is incorrect: 
 
+ ! # define _STLP_CONCAT(X,Y) X Y 
+ ! #  define _STLP_GCC_VERSUFFIX __GNUC__.__GNUC_MINOR__ 
+ ! # if (defined __GNUC_PATCHLEVEL__) && (__GNUC_PATCHLEVEL__ > 0) 
+ ! #  define _STLP_GCC_VERSION \ 
+ ! 	(__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + 
__GNUC_PATCHLEVEL__) 
+ ! # else 
+ ! #  define _STLP_GCC_VERSION \ 
+ ! 	(__GNUC__ * 10000 + __GNUC_MINOR__ * 100 ) 
+ ! # endif 
 
Since this 
+ ! #  define _STLP_GCC_VERSUFFIX __GNUC__.__GNUC_MINOR__ 
misses the patchlevel information (the path is 3.1.1 not simply 3.1) 
 
One way to handle this is: 
 
+ ! # define _STLP_CONCAT(X,Y) X Y 
+ ! # if (defined __GNUC_PATCHLEVEL__) && (__GNUC_PATCHLEVEL__ > 0) 
+ ! #  define _STLP_GCC_VERSUFFIX 
__GNUC__.__GNUC_MINOR__.__GNUC_PATHLEVEL__ 
+ ! #  define _STLP_GCC_VERSION \ 
+ ! 	(__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + 
__GNUC_PATCHLEVEL__) 
+ ! # else 
+ ! #  define _STLP_GCC_VERSUFFIX __GNUC__.__GNUC_MINOR__ 
+ ! #  define _STLP_GCC_VERSION \ 
+ ! 	(__GNUC__ * 10000 + __GNUC_MINOR__ * 100 ) 
+ ! # endif 
 
 
That way the suffix is either 3.1.1 or 3.1 (similarly for 3.2 and 
3.2.1). 
 
I am testing this on OO643C right now and will commit just this 
part. 
 
 
Aslo Ken, there seems to be some confusion about what environment 
variables are being used to set the name of the c compiler and the 
c++ compiler. 
 
Exactly how should these be set?  Specifically in stlport? 
What if any changes in the configure process are needed to handle 
this properly?  Are they actually in OO643C? 
 
Thanks, 
 
Kevin 
 

Created attachment 3467 [details]
new stlport patch for OO643C

The stlport version on OO643C being built is now 4.5 instead of 4.5.3
for all architectures.  I thought that the idea was only to use 4.5 on
Solaris?  Can someone explain what is intended as the final result?

The only outstanding issue is teh stlport compiler issue.

debian and otehr distributions do not use the patch number in the
include directory so we need a better patch.  We are going to work on
a patch of a value from configure to make this work.

Created attachment 4177 [details]
creates a GXX_INCLUDE variable for stlport part 2

Created attachment 4181 [details]
replacement file for stlport directory STLport-4.5.patch, not a patch!!!!

Hi Ken, 
 
Just to make sure I have this correct, I should be able to apply 
your 12-31 patch for config_office and replace the STLport-4.5.patch 
with the one from here and then stlport should build properly on 
both Debian gcc 3.2.X and on stock gcc 3.2.X. 
 
Is that right? 
 
If so, which tree is the patch against? 
 
Thanks, 
 
Kevin 
 

The patches are against OO643C.

To Kevin: Yes the instructions you have outlined are correct.  The
issue is whether they work for other platforms than debian, ie my
platform.

Hi Ken, 
 
I will test both patches on both my special OOo 1.0.2 build and OOo 
643C and let you know how it goes. 
 
You have alot of patches in this issue.  Which of these (besides 
this stlport include issue) in your opinion should be part of 
OOO_STABLE_1 and/or OO643C?  Are there any other build issues (issue 
number please) that you feell should make it into either of these 
builds. 
 
Thanks, 
 
Kevin 
 

Hi Ken, 
 
BTW: 
 
[kbhend@localhost kbhend]$ echo "#include <cstring>" | g++ -E -xc++ 
- | sed -n '/.*1*"\(.*\)\/cstring".*/s//\1/p' | head -1 
/usr/include/c++/3.2.1 
 
So everything should work fine on my box.  Does this work if CXX is 
defined to be ccache g++? 
 
If so, it looks good and I will do a final test with it on my 
version of OOo 1.0.2 for confirmation. 
 
Kevin 
 
 

Hi Ken, 
 
I applied the patch and used the new STLport-4.5.patch and did a new 
configure and a clean rebuild in stlport with absolutely no 
problems! 
 
Looks good to me. 
 
I approve them for OO643C and I will incorporate them into the final 
OOo 1.0.2 patch for Martin, Sander, Armin, and Stefan to consider. 
 
Nice job! 
 
Kevin 
 

The other patches have all been applied to OO643C in some manner.

I always use CXX="ccache gcc-3.2" for my standard build so yes it
works with ccache.

I will apply the patch tonight (my time) and close this issue.

This has been applied to OO643C.  The stlport patch must be applied to
base tree in order to continue working in the future.

This patch is also a candidate for PORTS and STABLE_1.  If required
reopen issue for application.

Broke the build.  I failed to do a complete build.  extra patches to
follow...

===================================================================
RCS file: /cvs/oo/external/berkeleydb/db-3.2.9.patch,v
retrieving revision 1.3
diff -u -b -B -r1.3 db-3.2.9.patch
--- db-3.2.9.patch	2001/06/11 14:09:22	1.3
+++ db-3.2.9.patch	2003/01/02 11:47:49
@@ -39,7 +39,7 @@
   ##################################################
   CPPFLAGS=	-I$(builddir) -I$(srcdir)/include @CPPFLAGS@
   CFLAGS=	 	-c $(CPPFLAGS) @CFLAGS@
-! CXXFLAGS=	-c $(SOLARINC) $(CPPFLAGS) @CXXFLAGS@
+! CXXFLAGS=	-c $(SOLARINC) $(CPPFLAGS)
-DGXX_INCLUDE_PATH="$(GXX_INCLUDE_PATH)" @CXXFLAGS@
   
   CC=		@MAKEFILE_CC@
   CCLINK=		@MAKEFILE_CCLINK@

===================================================================
RCS file: /cvs/tools/solenv/inc/settings.mk,v
retrieving revision 1.122.4.2
diff -u -b -B -r1.122.4.2 settings.mk
--- settings.mk	28 Nov 2002 14:40:59 -0000	1.122.4.2
+++ settings.mk	2 Jan 2003 13:49:38 -0000
@@ -1027,9 +1027,9 @@
 UNOIDLINC+=-I. -I.. -I$(PRJ) -I$(PRJ)$/inc -I$(PRJ)$/$(INPATH)$/idl
-I$(OUT)$/inc -I$(SOLARIDLDIR) -I$(SOLARINCDIR)
 
 .IF "$(remote)" != ""
-CDEFS= -D$(OS) -D$(GUI) -D$(GVER) -D$(COM) -D$(CVER) -D$(CPUNAME)
-D$(REMOTEDEF)
+CDEFS= -D$(OS) -D$(GUI) -D$(GVER) -D$(COM) -D$(CVER) -D$(CPUNAME)
-D$(REMOTEDEF) -DGXX_INCLUDE_PATH="$(GXX_INCLUDE_PATH)"
 .ELSE
-CDEFS= -D$(OS) -D$(GUI) -D$(GVER) -D$(COM) -D$(CVER) -D$(CPUNAME)
+CDEFS= -D$(OS) -D$(GUI) -D$(GVER) -D$(COM) -D$(CVER) -D$(CPUNAME)
-DGXX_INCLUDE_PATH="$(GXX_INCLUDE_PATH)"
 .ENDIF
 
 .IF "$(TIMELOG)" != ""

Hi Ken, 
 
What's up with the additional patches?  I did not think anything 
else used the c++ include directory the way stlport does? 
 
Are you sure these changes are really needed? If so, why didn't we 
have problems with building things under debian gcc 3.2.1? 
 
I am confused. 
 
Also, can you post all needed patches as attachments and not-inline.  
I seem to have trouble with patches copied and pasted from my 
browser window. 
 
Thanks, 
 
Kevin 
 

Hi Ken, 
 
Are you sure the STLport-4.5 patch is being properly set. 
 
I compared my LinuxPPCEnv.Set with your 
config_office_stlport_part1.patch to my previous LinuxPPCEnv.Set and 
the only differnce was: 
 
 setenv LINK "/usr/bin/gcc" 
+setenv GXX_INCLUDE_PATH "/usr/include/c++/3.2.1" 
 setenv COMMON_BUILD_TOOLS "$SRC_ROOT/external/common" 
 
So I simply can't see how adding this can change anything unless the 
stlport stl_gcc.h file gets delivered to the solver in such a way 
that the GXX_INCLUDE_PATH info is being dropped. 
 
Ideas? 
 
Kevin 

Hi Ken,  
  
So that must be it.  It must be that stl_gcc.h in the solver no  
longer has the information to build things properly without the  
GXX_INCLUDE_PATH properly being set.  
  
So unless we want to add one more define to the entire build  
(solenv/inc/target.mk would probably be the best place and output it 
along with LIBSTDCPP3, etc), 
 
We should probably revert these patches and find another solution 
that somehow includes GXX_INCLUDE_PATH into the stlport stl_gcc.h 
file as a define of some sort so that stlport stl_gcc.h stands 
alone. 
 
Kevin 
  

*** Issue 10418 has been marked as a duplicate of this issue. ***

Created attachment 4209 [details]
one patch to finally fix the stlport problem, includes armins problem

I just testet your patch with w32/4nt and found a problem:

+    +$(SED)    -e 's|GXX_INCLUDE_PATH|$(GXX_INCLUDE_PATH)|g' < ...

4nt chokes on the "|" pipe sign. I replaced the "|" by "#", this works
also with 4nt.

As I don't build with gcc I had a look at the changes you did.
Everything looks reasonable and with the "|" -> "#" change I would
approve the patch.

Revised patch is now applied.  This isssue is complete (for a second time)

All working branches current compile with gcc 3.2

Closing issue.