If you have seen the discussions regarding getting this right then you
would know the answer to the question you posed.  It is the only thing
that works.

If you can come up with a working patch and it works for me I am happy
to apply it.

mh->hjs, waratah: since the solver tar ball is not usable for most
people, we need to find another solution for this. unfortunatly I also
have no patch at hand ;).

Hi, 
 
I am not sure how to fix this for everyone.  It seems that Hamburg's ancient toolchain 
;-) always puts real C++ include headers in /usr/include/g++-v3/  so a relative path to 
find it was possible. 
 
The gcc people in their infinite wisdom have now changed the official include path to 
something along the lines of: 
 
/usr/include/c++/3.2.1/ for gcc 3.2.1 
 
But then one they opened that can of worms, some distributions starting changing 
things (they updated the compiler to be version 3.2.1 but did not change the  
C++ include paths and left them at /usr/include/c++/3.2/ 
 
So now we have differnt linux distributions with different locations for their 
official C++ headers that stlport has to find. 
 
Our only workable solution was to build the right include path up from config tests 
and store it in an environment variable and patch it into the stlport header so that the 
damn thing actually builds out of the box for most Linux users. 
 
The problem with that is that Hamburg uses the older tools and shares the solver in 
such a way that the stlport patch procedure we used to work around the lack of 
standardization for linux dists is impacting Hamburg. 
 
Is it true that every linux developer at Hamburg uses the exact same version of gcc 
and always puts their C++ native headers in exactly the same place relative to the 
stlport headers? 
 
Are no builds done with later toolchains?  If so, then how do you handle the stlport 
issue? 
 
If you look at the current stlport-4.5.patch used in 1.1 Beta 2 you will see: 
 
 
 # if (__GNUC__ >= 3) 
 
! #  define _STLP_NATIVE_INCLUDE_PATH ../g++-v3 
! #  define _STLP_NATIVE_OLD_STREAMS_INCLUDE_PATH ../g++-v3/backward 
 
  # elif (__GNUC_MINOR__ < 8) 
 
--- 226,235 ---- 
 
  # if (__GNUC__ >= 3) 
 
! /* properly determine the STLP_NATIVE_INCLUDE_PATH */ 
! #  define _STLP_NATIVE_INCLUDE_PATH GXX_INCLUDE_PATH 
! #  define _STLP_NATIVE_OLD_STREAMS_INCLUDE_PATH \ 
!           GXX_INCLUDE_PATH/backward 
 
 
We could easily change this patch to not change things unless gcc 3.1.0 and above 
was somehow defined? 
 
That will just delay the trouble until Hamburg moves to a newer toolchain and it will 
then run into the same problem we are seeing. 
 
Would making the hard coded path work only for gcc 3.1 and higher help? 
 
Kevin 
 

I suppose one way is to develop and include a 'fixup' script that
replaces any absolute patch that have made their way into solver with
correct ones? 

This would be akin to teh assumption everybody downloaded
config_office and dmake which we make anyways...

wouldn't it be possible to handle GXX_INCLUDE_PATH with a commandline
define which contains the correct relative path?
configure could determine this path and the STLport patch would fetch
it from the environment and append it to the compiler commanline.
similar changes would be required for SO/OOo compiler call and AFAIK
the external modules "icu" and "berkeleydb" as they use STLport.

yes, this would probably be an even better way

Forwarded for patches or reassignment.

some additional points to keep in mind when fixing this:

- looks like the "BUILD" pathproblem is connected (see
http://ooo.ximian.com/hackers-guide.html#section-10.10 )

- "dmake create_patch" doesn't work anymore. as the sed command
removes "GXX_INCLUDE_PATH" it won't appear in any regular created patch.

OK, the following patch fixes this problem and also issue 15939.

Instead of hardcoding GXX_INCLUDE_PATH via sed now the macro is set by
  -DGXX_INCLUDE_PATH=${GXX_INCLUDE_PATH}
in the makefiles.

Auses comments regarding predefined macros still apply, but as a macro
was used and still is used nothing got worse.
I was testing this patch on a FreeBSD system with gcc33, which had a
"i386" in its GXX_INCLUDE_PATH. This is a macro, you'll find a
#undef i386 in the new STPport-4.5.patch.
Predefined macros can be checked with: "g++ -E -dM - < /dev/null"

STPport-4.5.patch was generated with dmake patch / dmake create_patch.

Setting target to 1.1.1

Created attachment 8381 [details]
Patch for stlport/makefile.mk

Created attachment 8382 [details]
New STLport-4.5.patch

Set Issue type to patch.

Hi Sander, do we want this in cws_srx645_ooo111fix1?

If yes, have a look at the patch and approve ;-)

P.S.: STLport-4.5.patch already changed a bit in cws_srx645_ooo111fix1,
      I would have to create a new patch with the current changes
      included before committing.

looks ok - approved

Committed an adapted patch to cws_srx645_ooo111fix1.

Argh! I broke the build! I'm testing this:

Index: solenv/inc/settings.mk
===================================================================
RCS file: /cvs/tools/solenv/inc/settings.mk,v
retrieving revision 1.135.22.1
diff -u -r1.135.22.1 settings.mk
--- solenv/inc/settings.mk	15 Aug 2003 12:06:22 -0000	1.135.22.1
+++ solenv/inc/settings.mk	16 Oct 2003 21:35:04 -0000
@@ -1054,6 +1054,8 @@
 CDEFS= -D$(OS) -D$(GUI) -D$(GVER) -D$(COM) -D$(CVER) -D$(CPUNAME)
 .ENDIF
 
+CDEFS+= -DGXX_INCLUDE_PATH=$(GXX_INCLUDE_PATH)
+
 .IF "$(TIMELOG)" != ""
 CDEFS+=-DTIMELOG
 .ENDIF

fix now. If it works I'll commit it, otherwise I'll revert the
changes.

Sorry

I reverted the patch. The problem is that with the committed/reverted
changes the stlport module builds as desired, but
  stlport/config/stl_gcc.h
contains:
#  define _STLP_NATIVE_INCLUDE_PATH GXX_INCLUDE_PATH.
This header is copied to the solver and used later, therefore the
-DGXX_INCLUDE_PATH=$(GXX_INCLUDE_PATH) macro has to be set whenever
this header is used.

I don't know why my "hotfix" didn't work, but maybe it worked because
the build broke in python, at an ?unrelated? place.

Will investigate. 

Hmm, there must have been a Gremlin somewhere?! I tried the
+CDEFS+= -DGXX_INCLUDE_PATH=$(GXX_INCLUDE_PATH)
patch again, with a fresh cws_srx645_ooo111fix1 and
  stlport/makefile.mk          rev. 1.22.6.1.2.1
  stlport/STLport-4.5.patch    rev. 1.11.6.2.2.2
and now the build continues.

vq->ause: Do you have a GXX_INCLUDE_PATH environment variable in the
          SO build environment?
          Do you have a better idea where to place the
           -DGXX_INCLUDE_PATH=$(GXX_INCLUDE_PATH) switch instead of
          settings.mk?

I'll report when the full build completes with this patches.

- yes, our environment knows GXX_INCLUDE_PATH
- i think "settings.mk" is a fine places as this define might be
usefull for all platforms using gcc. but it should be restricted to
"$(COM)"=="gcc".

OK, so in principle this works, but the build just stopped
in berkeleydb.

I'm curious which external projects use stlport headers and therefore
need patches :-(

this is quite easy to find out as these modules either have their
makefiles extended with "*SOLARINC*" oder "*stl*" by the patch or use
dmake makefiles which need no further change.

Its actualy bad if they do extend with "stl" becuase that will 
break building with an external STLport (and also break IRIX) - 
the makefiels should really use more generic ways (the stlport 
variable is set to either the path to stl headers or no_stlport)

vq->svesik: It was only berkeleydb, there was $(SOLARINC) added to the
patch. With the following two patches the full build completed.
(Tested on FreeBSD 4.8 with gcc 3.2.3.)

I know that it is a big "no no" to patch a patch, but in this case I
only added -DGXX_INCLUDE_PATH=$(GXX_INCLUDE_PATH) after the $(SOLARINC),
I guess this is save.

The other patch is the patch to settings.mk with the changes ause
suggested.

Created attachment 10430 [details]
Patch to the berkeleydb patch

Created attachment 10431 [details]
Patch to settings.mk

I committed
   stlport/makefile.mk          rev. 1.22.6.1.2.1
   stlport/STLport-4.5.patch    rev. 1.11.6.2.2.2
again and also applied the berkeleydb.diff and solenv.diff.

Created attachment 11131 [details]
Fixes broken build on IRIX 6.5 with gcc 3.3

diff I attached yesterday against STLport-4.5.patch fixes build error 
on IRIX with gcc 3.3. I couldn't get the bug to reopen for some 
reason...


scott

I committed Scotts last patch to cws_srx645_ooo111fix1, resolving issue
as FIXED.

vq:  Can you keep 680 sourceline synced.

vq->waratah: That will produce more merge conflicts. I can do it, but
I thought the changes from ...fix1 will propagate to src680 once it
gets integrated.

close issue.