[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

--- Comment #94 from pinskia at gcc dot gnu dot org 2006-04-26 02:13 --- *** Bug 26846 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c++/26846] hidden visibility of static member in class derived from hash_map changes to default visibility

--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-26 02:13 --- Oh, if you had put how you involved gcc in the comments instead of in build script, I would have seen what the problem is. Anyways this is a dup of bug 19664. The problem is the libstdc++'s headers don't have push

Results for 4.0.4 20060422 (prerelease) (Debian 4.0.3-2) testsuite on arm-unknown-linux-gnu

LAST_UPDATED: Sat Apr 22 08:38:50 UTC 2006 (revision 113170) Native configuration is arm-unknown-linux-gnu === libffi tests === Running target unix XPASS: libffi.call/closure_fn0.c execution test XPASS: libffi.call/closure_fn1.c execution test XPASS: libffi.call/closure_fn2.c ex

Bug#364820: Add /usr/lib/jni to the default java.library.path

On 4/25/06, Shaun Jackman <[EMAIL PROTECTED]> wrote: > Package: gcj-4.0 > Version: 4:4.0.3-3 > Severity: important > Justification: violates a *should* directive of the Debian Policy for Java ... > [1] http://www.debian.org/doc/packaging-manuals/java-policy/x105.html It seems that a package `shoul

Bug#364820: Add /usr/lib/jni to the default java.library.path

Package: gcj-4.0 Version: 4:4.0.3-3 Severity: important Justification: violates a *should* directive of the Debian Policy for Java The default java.library.path of applications compiled using gcj does not include /usr/lib/jni. The Debian Policy for Java [1] states that /usr/lib/jni *should* be the

Bug#364819: gij-4.1: bus error on hppa.

Package: gij-4.1 Version: 4.1.0-1 Severity: serious Hi, When building ecj-bootstrap on hppa, we get the following error: gij-4.1 \ -classpath build/bootstrap/ecj.jar:/usr/share/ant/lib/ant.jar \ org.eclipse.jdt.internal.compiler.batch.Main \ -bootclasspath /usr

[Patch] #14: select the proper body for package indepsw (minor upstream bug exposed)

ada-link-lib.dpatch exposes a minor bug in the build machinery for the gnat tools. One of the Ada packages that make up the gnat tools is indepsw (platform-independent switches). It has one spec, indepsw.ads, and several bodies to choose from depending on the platform. Before the patch, src/gcc/

Re: qt4-x11

Wouter Verhelst <[EMAIL PROTECTED]> writes: > On Tue, Apr 25, 2006 at 09:47:19AM -0500, Stephen R Marenka wrote: >> On Tue, Apr 25, 2006 at 08:31:07AM -0500, Stephen R Marenka wrote: >> > On Tue, Apr 25, 2006 at 03:22:50PM +0200, Wouter Verhelst wrote: >> > > qt4-x11 needs to be rebuilt on m68k, a

Re: qt4-x11

On Tue, Apr 25, 2006 at 09:47:19AM -0500, Stephen R Marenka wrote: > On Tue, Apr 25, 2006 at 08:31:07AM -0500, Stephen R Marenka wrote: > > On Tue, Apr 25, 2006 at 03:22:50PM +0200, Wouter Verhelst wrote: > > > qt4-x11 needs to be rebuilt on m68k, anything using it currently will > > > give errors

Re: qt4-x11

On Tue, Apr 25, 2006 at 08:31:07AM -0500, Stephen R Marenka wrote: > On Tue, Apr 25, 2006 at 03:22:50PM +0200, Wouter Verhelst wrote: > > qt4-x11 needs to be rebuilt on m68k, anything using it currently will > > give errors that libXcursor.la can't be found. > > Anyone know whether GCC 4.1 has th

Re: qt4-x11

On Tue, Apr 25, 2006 at 03:22:50PM +0200, Wouter Verhelst wrote: > Hi, > > qt4-x11 needs to be rebuilt on m68k, anything using it currently will > give errors that libXcursor.la can't be found. > > Unfortunately, GCC 4.0 currently ICEs on QT4. fwiw kdepim and koffice ICE the same way. > Anyone

qt4-x11

Hi, qt4-x11 needs to be rebuilt on m68k, anything using it currently will give errors that libXcursor.la can't be found. Unfortunately, GCC 4.0 currently ICEs on QT4. Anyone know whether GCC 4.1 has the same issues? If not, should we proceed to build QT with GCC 4.1, or is that not advisable? -