Caolan McNamara wrote:
> What bothers me is that *some* of the older gcc's have
problems with
> visibility and system stl not working together. I don't
know if the
> current default mac compiler is one of the broken ones.
I know that our
> gcc-4.1.2 with backports is ok f.e.
>
Since I try to to be as true to Slackware x86 as possible I
tend to
patch only
if it is really necessary. I have also tried to build with
GCC 4.2.0 and
Glibc 2.6
but I got the same error message. I also tried
--with-system-stl but
that resulted
in the same thing so I am at a loss what to try next.
Nonetheless, I reinstalled the system from scratch a few
days ago to
exclude any
possible traces of system corruption that may have
occurred.
> Ideally we would be able to detect this in configure,
but I don't know
> how to test for bustage :-(. If we could detect
potential bustage then
> I'd say we just setup configure to automatically
default to
> --disable-stlport4 when using gcc for all platforms
when it is known
> safe, except for a short table of established ports
that are considered
> to need stlport so that 3rd party foo works with them,
i.e. basically
> just linux i386. *Perhaps* also linux ppc but I
wouldn't really consider
> that an established in a "people have actually
created third party c++
> addons for them" abi.
>
That would be pretty helpful. I would like to know why
STLPort4 has been
kept around
for so long, since I can't even get it to build on x86
anymore. I could
build STLPort
5.1.3 with minor makefile alterations on both x86 and MIPS.
> FWIW: htt
p://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664 is the
problem I
> refer to, so all gcc + libstdc++ 4.2.0 combos should be
ok. We can test
> for that version no and be sure it's ok, but plenty of
olders gcc's are
> also ok that a simple version test would exclude.
>
> C.
>
> Note that in stlport there is a little hack in place
that bounces some
> of the sgi extensions which are in a __gnu_cxx
namespace for system stl
> into the std namespace so that no other mods are
required in our
> codebase, so on occassion the bouncer headers may need
some other newly
> used methods added to them.
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribe porting.openoffice.org
> For additional commands, e-mail: dev-helpporting.openoffice.org
I will free some space on this small hard drive and try to
build
OpenOffice.org without
stlport4 as you told me.
Sunil
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeporting.openoffice.org
For additional commands, e-mail: dev-helpporting.openoffice.org
|