Issue 18063 - FreeBSD-4.8: Fix the "i386" macro expansion problem
Summary: FreeBSD-4.8: Fix the "i386" macro expansion problem
Status: CLOSED FIXED
Alias: None
Product: Build Tools
Classification: Code
Component: code (show other issues)
Version: OOo 1.1 RC2
Hardware: PC FreeBSD
: P3 Trivial (vote)
Target Milestone: OOo 1.1 Beta2
Assignee: Martin Hollmichel
QA Contact: issues@tools
URL:
Keywords:
Depends on:
Blocks: 18060
  Show dependency tree
 
Reported: 2003-08-09 10:00 UTC by quetschke
Modified: 2004-02-07 07:04 UTC (History)
3 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
patch for stlport (447 bytes, patch)
2003-08-09 11:48 UTC, maho.nakata 		no flags Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description quetschke 2003-08-09 10:00:38 UTC 
To build stlport with GXX_INCLUDE_PATH set to (e.g.):
  /usr/local/lib/gcc-lib/i386-portbld-freebsd4.8/3.3.1/include/c++
it is necessary to undefine the i386 macro before substituting the
GXX_INCLUDE_PATH value. The i386 macro is not used in the stlport
sources and no sane OS would use the version of this macro without
leading underscores.

I know that we don't patch Patches, but the following patch demonstrates
what has to be done with stlport/STLport-4.5.patch:

diff -u -r1.11.2.2 STLport-4.5.patch
--- stlport/STLport-4.5.patch	4 Aug 2003 04:22:20 -0000	1.11.2.2
+++ stlport/STLport-4.5.patch	8 Aug 2003 15:05:21 -0000
@@ -254,11 +254,12 @@
   
   # elif (__GNUC_MINOR__ < 8)
   
---- 244,253 ----
+--- 244,254 ----
   
   # if (__GNUC__ >= 3)
   
 ! /* properly determine the STLP_NATIVE_INCLUDE_PATH */
+! #undef i386
 ! #  define _STLP_NATIVE_INCLUDE_PATH GXX_INCLUDE_PATH
 ! #  define _STLP_NATIVE_OLD_STREAMS_INCLUDE_PATH \
 !           GXX_INCLUDE_PATH/backward
Comment 1 quetschke 2003-08-09 10:02:13 UTC 
Target OOo 1.1.1
Comment 2 maho.nakata 2003-08-09 11:48:04 UTC 
Created attachment 8365 [details]
patch for stlport
Comment 3 foskey 2003-08-09 12:22:02 UTC 
Patch approved.
Comment 4 maho.nakata 2003-08-09 12:33:20 UTC 
Hm it doesn't help for 5-CURRENT...though.
Comment 5 maho.nakata 2003-08-09 16:04:05 UTC 
Following patch is needed.

@@ -274,7 +275,7 @@
   # endif
   
 + #ifdef __FreeBSD__
-+ # include <../wchar.h>
++ # include <wchar.h>
 + #endif
   # include <stl/_cwchar.h>
   
Volker, this issue might be solved, i think.
Comment 6 quetschke 2003-08-09 16:18:41 UTC 
Maho, I approve your patch to also fix 5-CURRENT. This solves the build
problems for stlport for FreeBSD. :-)

But we need a branch to commit it to, before we can mark this issue
fixed.

   Volker
Comment 7 maho.nakata 2003-08-10 10:44:11 UTC 
Hi Volker,
My former patch doesn't help for 5-CURRENT.
This is my failure.
Following patch is *much* safer.

--- STLport-4.5.patch.orig      Sun Aug 10 18:04:04 2003
+++ STLport-4.5.patch   Sun Aug 10 18:34:18 2003
@@ -274,7 +275,7 @@
   # endif
   
 + #ifdef __FreeBSD__
-+ # include <../wchar.h>
++ #include _STLP_NATIVE_C_HEADER(wchar.h)
 + #endif
   # include <stl/_cwchar.h>
Comment 8 pavel 2003-10-09 17:47:24 UTC 
Volker, which one is correct? I will test it, apply it then.
Comment 9 quetschke 2003-10-09 17:58:51 UTC 
Argh, I see the problem, the last one, from maho:

--- STLport-4.5.patch.orig      Sun Aug 10 18:04:04 2003
+++ STLport-4.5.patch   Sun Aug 10 18:34:18 2003
@@ -274,7 +275,7 @@
   # endif
   
 + #ifdef __FreeBSD__
-+ # include <../wchar.h>
++ #include _STLP_NATIVE_C_HEADER(wchar.h)
 + #endif
   # include <stl/_cwchar.h>

and my first patch also with
+! #undef i386
 
See
<http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/editors/openoffice-devel/files/patch-stlport%3a%3aSTLport-4.5.patch?rev=1.4&content-type=text/plain>
for the complete patch.

Sorry, approved my me.

Volker
Comment 10 pavel 2003-10-09 19:19:32 UTC 
Fixed in cws_srx645_ooo111fix1.
Comment 11 Martin Hollmichel 2004-02-05 12:49:33 UTC 
mark as verified.
Comment 12 Martin Hollmichel 2004-02-05 12:51:11 UTC 
close issue, feel free to reopen if there is a problem left.
Comment 13 Martin Hollmichel 2004-02-07 07:04:04 UTC 
close issue.