Package: gcc-snapshot
Version: 20040717-1
Severity: wishlist
I'm not sure how often you usually upgrade to the latest version from
CVS. When it's possible, it would be great to see this happen. I just
had one of my bugs reported as fixed, and I'd like to check it and see
if no new bugs are unc
ing/Procedure.class:0: error: cannot find file for class
java.lang.Object
because gcj-3.3 has its classpath set to
/usr/share/java/libgcj-3.3.4.jar, which is included in libgcj4-common.
Daniel
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (700, 'testing
Package: gcc-2.95
Version: 1:2.95.4-1
Severity: normal
This version of the C compiler generates an Internal Compiler Error
with the following input:
- bug.c -
enum tipo { tc_int, tc_float, tc_nulo };
struct dato_vm
{
enum tipo t;
union
{
int
Package: gcc-snapshot
Version: 20040613-1
Severity: wishlist
Since this snapshot is especially usefull for debugging recent versions
of gcc, it would seem to me a good idea not to strip the executables,
but to keep as much debugging symbols as possible. Is there a compelling
reason not to do t
Package: g++-6
Version: 6.2.0-13
Severity: minor
While developing a custom implementation of std::make_index_sequence
for compatibility with previous versions of gcc, I ran into an
internal compiler error. I'm attaching the output of creduce on the
source code, which still gives the same ICE.
--
is not available.
Best wishes,
Daniel Auth
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64
(x86_64)
Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
S
, discussed here:
https://lists.debian.org/debian-devel/2021/07/msg00046.html
https://lists.debian.org/debian-devel/2021/07/msg00048.html
Thank you!
Daniel Lewart
Urbana, Illinois
Also, discussed here:
https://lists.debian.org/debian-devel/2021/07/msg00046.html
https://lists.debian.org/debian-devel/2021/07/msg00048.html
Thank you!
Daniel Lewart
Urbana, Illinois
Also, discussed here:
https://lists.debian.org/debian-devel/2021/07/msg00046.html
https://lists.debian.org/debian-devel/2021/07/msg00048.html
By the way, buster had:
* gcc-7-base: libs/optional
* gcc-8-base: libs/optional
Thank you!
Daniel Lewart
Urbana, Illinois
=992477
Thank you!
Daniel Lewart
Urbana, Illinois
Followup-For: Bug #1015185
Hi,
This is standard behavior with the GCC packages, sadly. See:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894014
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783876
Regards,
Daniel.
please be rolled back until it can be root-caused and fixed?
Cheers,
Daniel
e collection of patches that
distributors ship with GCC to shrink over time, not grow...
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
It was pretty easy to fix, though. In libstdc++/Makefile.in, after the
long assignment to AM_MAKEFLAGS, add:
FLAGS_TO_PASS = $(AM_MAKEFLAGS)
I'm not 100% sure that's correct; I'll check on the GCC lists.
Meanwhile, what should I do with this build? Wait for a new one?
--
Da
before it goes into the archive.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
the end
> because it tried to install stuff into /usr/local
>
> After 'apt-get source gcc-3.1' i ran 'dpkg-buildpackage -rfakeroot'
> Here's the error i get:
Add:
FLAGS_TO_PASS = $(AM_MAKEFLAGS)
to libstdc++/Makefile.am. I posted about this last week, b
r the next upload.
Same for altivec.h on powerpc, if you didn't get that at the same time.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ost of javac's options. Please feel
> free to submit a gcj-wrapper, which can be used as an javac
> alternative.
Should it really provide javac? Javac is expected to compile to
bytecode, and gcj doesn't do that.
--
Daniel Jacobowitz Carnegie Mellon University
p in evaluating the patch. All you need is a lot of
> disk space and spare cycles.
I agree. There's very little point in adding this patch, especially to
a version of GCC we're trying to obsolete soon.
--
Daniel Jacobowitz Carnegie Mellon University
Mont
/debug instead? Ncurses
and libc already both use this convention.
Uli, try LD_LIBRARY_PATH=/usr/lib/libstdc++_debug for now, by the way.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
--
To
ally see the source, you must have
> the source avilable, and gdb needs to know where it is. If it's not in
> "/home/doko/packages/..." then you can set a variable inside gdb to tell
> it where to look.
The command is 'dir', for reference. Follow it by the appropria
Package: gcc
Version: 2:2.95.4-14
Severity: normal
-- System Information
Debian Release: 3.0
Kernel Version: Linux robust.colorado.edu 2.4.17 #1 SMP Sun Apr 21 21:05:15 MDT
2002 i686 unknown
Versions of the packages gcc depends on:
ii cpp2.95.4-14 The GNU C preprocessor.
ii c
dn't instantly disappear when gcc 3.2 arrived in the
> pool.
Why would it be any cleaner? Everything should be rebuilt with gcc
3.2 as soon as possible, and there is no point in allowing packages to
continue to be built with 3.1.1.
--
Daniel Jacobowitz Carne
of style and not
> syntax - since the C syntax doesn't require the spaces, the preprocessor
> requirement is the more unexpected by a C/C++ programmer.
Since the 3.x preprocessors don't exhibit the bug, GCC doesn't need to
be fixed; if the kernel
On Mon, Jul 29, 2002 at 08:45:30PM -0400, Jack Howarth wrote:
> Daniel,
>Well if gcc 3.1.1 instantly disappears the moment gcc 3.2 hits the pool,
> won't that force openoffice/stl to deinstall on a dist-upgrade? It would
> nicer if we allows folks a grace period for their ap
On Mon, Jul 29, 2002 at 10:32:03PM -0400, Jack Howarth wrote:
> Daniel,
>What about the libgcc_s.so.1? I assume we are assured of compatibility
> in using a libgcc_s.so.1 from gcc 3.2 with binaries built with gcc 3.1.1
> then?
Yes.
--
Daniel Jacobowitz
Package: gcj-3.0
Version: 1:3.0.4-12
Severity: minor
[EMAIL PROTECTED]:~% ls -l /usr/share/man/man1/gcj-3.0.1.gz
-rw-r--r--1 root root 6230 Jul 20 22:05
/usr/share/man/man1/gcj-3.0.1.gz
[EMAIL PROTECTED]:~% dlocate /usr/share/man/man1/gcj-3.0.1.gz
gcj-3.0: /usr/share/man/man1/gcj-
xceptions in any way then yes, almost
certainly.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
hat
your loop disappears, as I understand it. (int) [unsigned] may be
assumed to be non-negative and thus oldi+1 > oldi.
> Anyone care to jump in? :)
Don't take my uneducated word for it. Ask comp.lang.c; they know these
things.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
ed reference to `__cxa_atexit'
> collect2: ld returned 1 exit status
>
> I'm not sure about __dso_handle, but I clearly remember having to tweak a
> rules.def setting related to atexit in GCC 3.0 and 3.1, and I don't see it
> anywhere obvious in 3.2 - and it's explicitly enabled in debian/rules2.
This looks like you have a linker bug relating to weak symbol
references - both of them are weak, I believe...
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
#ifdef macros in various .c files)
Autoconf sets it. You need to check in the build tree whether it is
set or not. If you're using too old a binutils this could fail, or if
there is some problem with your tools or the test...
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
t
> means there is no way to build 64-bit binaries, including the
> kernel.
>
> This should be just a configuration change when building the
> package.
Yes. Ben is working on a way to enable -m64 without also making it the
default; he said he'd look at it tonight.
ecause set has:
typedef typename _Rep_type::const_iterator iterator;
i.e. set's iterators are actually const_iterators. The STL reference
says:
Const iterator used to iterate through a set. (Iterator and
const_iterator are the same type.)
So I believe this isn't a bug; there are
ble-__cxa_atexit
+ --without-included-gettext
+
+ifneq ($(with_cxa_atexit),yes)
+ CONFARGS += --disable-__cxa_atexit
+endif
ifeq ($(with_java),yes)
CONFARGS += --enable-java-gc=boehm
And that doesn't look right at all.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
l
> ldl $2,0($3)
> stl $4,0($1)
> lda $2,1($2)
> stl $2,0($3)
I don't see the problem. Volatile in C doesn't provide any sort of
barrier; you have to place one yourself if you want one. It only
guaranatees that the two accesses t
On Tue, Oct 15, 2002 at 08:28:02AM +1000, Herbert Xu wrote:
> On Mon, Oct 14, 2002 at 06:01:24PM -0400, Daniel Jacobowitz wrote:
> >
> > I don't see the problem. Volatile in C doesn't provide any sort of
> > barrier; you have to place one yourself if you want one
On Tue, Oct 15, 2002 at 12:09:56PM +1000, Herbert Xu wrote:
> On Mon, Oct 14, 2002 at 07:01:46PM -0400, Daniel Jacobowitz wrote:
> >
> > > My copy of C99 says:
> > >
> > > 5The least requirements on a conforming implementation are:
> > > - At
On Mon, Oct 14, 2002 at 10:31:03PM -0400, Daniel Jacobowitz wrote:
> On Tue, Oct 15, 2002 at 12:09:56PM +1000, Herbert Xu wrote:
> > On Mon, Oct 14, 2002 at 07:01:46PM -0400, Daniel Jacobowitz wrote:
> > >
> > > > My copy of C99 says:
> > > >
> >
xed in the GCC CVS tree just this week,
which means a fix will probably be in 3.3 but no earlier.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
cessor.
> ii cpp-2.95 2.95.4-12 The GNU C preprocessor.
> ii gcc-2.95 2.95.4-12 The GNU C compiler.
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
he output from ldd -v is below.
Presumably something is not linking using GCC 3.2. Are you linking
using g++ instead of g++-3.2?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
On Thu, Oct 24, 2002 at 04:48:25PM -0400, Gregory Seidman wrote:
> Daniel Jacobowitz sez:
> } On Thu, Oct 24, 2002 at 04:34:07PM -0400, Gregory Seidman wrote:
> } > I am developing a program using g++ 3.2. When I added a dynamic_cast, it
> } > started segfaulting on it. In search
ce() in
glibc. In fact, in general it's usable; I see special support for PPC,
i386, ARM, s390, and HPPA. And it's more reliable than your method,
too.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
call the c3 a 486... perhaps the kernel is
the one which should change. The best place to pursue this
conversation is probably on the GCC list or on linux-kernel, however.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
ever, either, I
think. I've added them.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
ort of problem.
Don't throw stones. Instead politely suggest to debian-gcc that the
link be added and gcc-2.95 be reuploaded.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
2.3.1-3 GNU C Library: Shared libraries
> an
> ii libgcc11:3.2.1-0pre6 GCC support library.
>
> -- no debconf information
>
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
mp/buildd/gcc-3.0-3.0.4ds3'
make: *** [stamps/05-build-stamp] Error 2
Unfortunately, at least one package (gconf2) build-depends on
gcc-3.0.
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux frobnitz 2.4.19 #2 Sun Aug 18 15:52:57 PDT 2002 i686
unknown unknown G
gt; You can try tracking the gcc-snapshot package, since you're using unstable.
... - but we may want to consider examining the rhl8 CVS branch for
patches; it would be nice to support this in our 3.2 packages if it's
relatively painless, and I think it is. Large, but painless, since RH
did the work already.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
am like `tcov'. Note,
however, that the format of the data is not what `tcov' expects.
Eventually GNU `gprof' should be extended to process this data.
Paul, scroll down a little to find -fprofile-arcs -ftest-coverage,
which is what you want now.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
us up, besides someone to manage the process?
If not, it sounds like it's time to begin.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
On Sun, Dec 15, 2002 at 09:59:34PM -0500, Ben Collins wrote:
> On Sun, Dec 15, 2002 at 11:16:41PM +, Dr. David Alan Gilbert wrote:
> > * Daniel Jacobowitz ([EMAIL PROTECTED]) wrote:
> > > Reference: http://people.debian.org/~rmurray/c++transition.html, which
> > > s
gDF .text0045 GLIBC_2.1.3 __cxa_atexit
That means atexit is "hidden". It is not available for compile-time
linking. mklibs isn't handling that correctly; easier is to avoid it.
Looks like it needs to search libc_nonshared.a in addition to
libc_pic.a.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
On Mon, Dec 16, 2002 at 09:30:32AM +0100, Matthias Klose wrote:
> Daniel Jacobowitz writes:
> > On Sun, Dec 15, 2002 at 09:59:34PM -0500, Ben Collins wrote:
> > > On Sun, Dec 15, 2002 at 11:16:41PM +, Dr. David Alan Gilbert wrote:
> > > > * Daniel Jacobo
asonable, I suppose. It would have to be for the oldlibs
version; then we could do it after we're into the transition. The new
versions should go in the normal locations IMO.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
On Thu, Dec 26, 2002 at 12:48:08AM +0100, Alberto Rodriguez Ortega wrote:
> Package: gcc-3.2
> Version: 1:3.2.2-0pre2
> Severity: normal
> Tags: sid
To do what? When compiling what?
This isn't a bug report.
--
Daniel Jacobowitz
MontaVista Software
n engine... however, I believe that
what I'm thinking of didn't affect 5.6.1, so take this with a grain of
salt.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
s started in the background, and after the testsuite
> finishes, it is killed ... should be killed. There is still one
> logwatch process hanging around. Any idea, why and how to kill this
> one?
Try adding "exit 0" to the end of cleanup(){}; then it works for me.
--
Daniel
ard, this is correct. LONG_LONG_MAX
is not mentioned at all.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
inished. The script is fairly clearly broken (you trap
> the SIGHUP you send it but then don't exit from the function you trap
> into?) and the only reason it finished at all on the Debian buildds is
> that sbuild's inactivity timeout kicked in[1]. Doh.
Yeah. This is fixed in
Whoops, forgot to Cc this to the bug report...
Matthias Klose <[EMAIL PROTECTED]> writes:
> Daniel Schepler writes:
> > Package: gcc-3.0
> > Version: 3.0.4ds3-13
> > Severity: serious
> >
> > When I try to build gcc-3.0 on unstable, first there are bison
ng libjava.
If I had to guess, I'd say that it ran out of memory. Libjava is
stupidly large.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
e x = 3 ;
>
> bound( x , u ) ;
>
> assert( u >= x ) ;
> assert( 2.5*u >= 2.5*x ) ; // fails!!!
The compiler is certainly allowed to compute 2.5*u at compile time. It
does so using an extremely high precision real library, if I recall
correctly. This could be a bug in
le?
Look at the 3.2 documentation...
Use `-ffloat-store' for such programs, after
modifying them to store all pertinent intermediate computations
into variables.
Do you get the expected results if you do this?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
r, linker and binary utiliti
ii cpp-3.23.2.2-0pre3The GNU C preprocessor
ii gcc-3.2-base 3.2.2-0pre3The GNU Compiler Collection (base package)
ii libc6 2.3.1-9GNU C Library: Shared libraries and Timezone
ii libgcc13.2.2-0pre3GCC support library
kx ) ; // doesn't fail.
> #endif
Yup, that's C for you. The former uses the value of 2.5*u, the latter
uses the value of ku. You can see how this works by declaring ku
volatile and looking at the assembly; it'll be reloaded in the second
case but not t
On Wed, Jan 15, 2003 at 02:15:04AM -0600, Daniel E Baumann wrote:
> Package: libstdc++5
> Version: 1:3.2.2-0pre5
> Severity: important
>
> When running my c++ program from inside gdb I get the following:
>
> [EMAIL PROTECTED]:~/software/src/cvs/gsim/src/examples/mm1$ gdb .l
On Wed, Jan 15, 2003 at 05:13:14PM -0600, Daniel E Baumann wrote:
> On Wed, Jan 15, 2003 at 03:05:55PM -0500, Daniel Jacobowitz wrote:
> > On Wed, Jan 15, 2003 at 02:15:04AM -0600, Daniel E Baumann wrote:
> > > Package: libstdc++5
> > > Version: 1:3.2.2-0pre
at a
> binary is optmized as i686 with cmov instruction by gcc. You need to
> consider how to fix. I anticipate that it may need to make gcc
> non-cmov aware.
Let's not do anything about this until someone gets clarification from
GCC that -march=i686 is not actually supposed to be a 686, OK?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
On Fri, Jan 17, 2003 at 01:16:21PM -0600, Daniel E Baumann wrote:
> On Fri, Jan 17, 2003 at 09:32:38AM -0500, Daniel Jacobowitz wrote:
> > On Wed, Jan 15, 2003 at 05:13:14PM -0600, Daniel E Baumann wrote:
> > > On Wed, Jan 15, 2003 at 03:05:55PM -0500, Daniel Jacobowitz wrote:
&
situation is as follows
> >
> > gcc "i686" definition is wrong. The gcc people wont fix it because the 686
> > definition without cmov is mostly useless anyway.
>
> Thanks for your explanation. Hmm. "cmov" is really key instruction...
>
> I th
t case is actually the bug, but I'm
not sure. C doesn't guarantee order-of-operation across an equals
sign; it's not a sequence point. The function call is a sequence point
but it isn't specified which side of the sequence point the increment
will happen on.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
rchs := :netbsd-i386:
ifeq (:$(DEB_HOST_ARCH):, $(findstring :$(DEB_HOST_ARCH):,$(no_cxa_archs)))
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
l think this is a gcc problem, at least post a test
> case...
Neil Booth points out that some XFS versions have a problem with not
NULL-padding a mmap(). That's probably it.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
C manual... aha, it is. Try "info
cpp-3.2 If".
Any identifier without a definition is considered to be 0 in an #if.
Macro substitution is performed on TEST_THREE, which converts it to the
identifier TEST_THREE - still not #define'd. So it's 0.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
reopen 180306
thanks
Sorry about that, folks, I just assumed it had been filed on GCC.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
.
>
> So, to be clear, it's impossible to compare RLIMIT defines in the
> preprocessor, then?
They're enums, right? Yes, it's impossible. Enums aren't processed
until a later stage of compilation, when preprocessing is already
finished.
The only thing "#
first label, and goes until the
end of the case block. So it's in scope at CHOICE_B. But its
constructor wasn't called
> switch (choice) {
> case CHOICE_A:
> someclass obj1(&commonobj);
>
> break;
> case CHOICE_B:
> someotherclass obj2(&commonobj);
>
> break;
> default:
> break;
> }
> }
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
since as said libstdc++5-dev is
> pulled in by xlibmesa-glu-dev.
This sounds like a bug in xlibmesa-glu-dev; that symbol comes from
libsupc++, and if the C++ library is linked using g++ it'll be picked
up correctly. Or are you using a .a archive of glu into the plugin?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
t; think we should not add this compat-patch even if sid binaries causes
> > > such unresolved symbol bug.
> > No. We only add symbols for the woody->sarge transition.
>
> So, is it debian specific patch?
Uh, I don't think it should be.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
a, TB b, TC c);
> > >
> > > int main()
> > > {
> > > foobar(1,2,3);
> > > return 0;
> > > }
> > >
> > > void foobar(TA a, TB b, TC c)
> > > {
> > > printf("a == %i claims %x\n", a, &a);
> &
can, it's just a bit awkward to use. A couple of wrapper
scripts a la
#!/bin/sh
exec $HOME/lib/ld.so --library-path $HOME/lib:$HOME/usr/lib \
$HOME/usr/bin/gcc $*
> 2) oddities with stdlib.h installed with the above procedure. Some
>defines are missing.
It should work, but you'll have to be more specific about the problems.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
cc-2.95, I did not file it earlier because I
> was hoping that it might be gone in gcc-3.2. The first builds in early
> 2002 were done with -O and then with -O0 afterwards.
>
> You can get the source file at
>
> http://people.debian.org/~mbanck/lebedev.c
FYI, there should be a new binuti
other errors that your linker command
> line may have caused.
Well, presumably he is linking using gcc to avoid libstdc++; is there
anything besides the missing library which g++ would change?
Fernando, you may want to try adding -lsupc++ when building with GCC
3.2.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Package: libstdc++5-dev
Version: 1:3.2.3-0pre4
Severity: grave
The version of libstdc++5-dev indicated above depends on LIBC_DEV, a
package which does not exist.
Daniel
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux torrent.burrows.local 2.4.20 #4
e fixed in gcc 3.3 (at a performance penalty; we need to
think about providing the i486 version also).
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
On Sat, Mar 15, 2003 at 08:32:26PM +0100, Matthias Klose wrote:
> Daniel Jacobowitz writes:
> > On Wed, Mar 12, 2003 at 12:49:44PM +0100, Sebastian Wilhelmi wrote:
> > > Package: libstdc++5-dev
> > > Version: 1:3.2.3-0pre5
> > > Severity: normal
> > &g
On Sat, Mar 15, 2003 at 04:49:55PM -0500, Phil Edwards wrote:
> On Sat, Mar 15, 2003 at 08:32:26PM +0100, Matthias Klose wrote:
> > Daniel Jacobowitz writes:
> > > On Wed, Mar 12, 2003 at 12:49:44PM +0100, Sebastian Wilhelmi wrote:
> > > >
> > > > The
linux SMP, or will STL be forbidden
> while using SMP for a while ?
Huh? Is this your own installation of GCC 3.2? Our
i386-linux/bits/atomicity.h contains the atomic operations, not a
single-threaded version.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
d symbol linking bug
90C 02/17 Elias Athanasop (0.9K) |->
91 r + 02/23 Elias Athanasop (1.4K) | `->
92 N 02/25 Alan Modra (3.7K) `->
The patch in Alan's message needs to be tested. It was originally
found on PPC building wxWindows.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
On Mon, Mar 17, 2003 at 08:37:30PM +0100, Bo Lorentsen wrote:
> On Mon, 2003-03-17 at 18:32, Daniel Jacobowitz wrote:
> >
> > Huh? Is this your own installation of GCC 3.2? Our
> > i386-linux/bits/atomicity.h contains the atomic operations, not a
> > single-threaded v
es; else echo no; fi)
>
> I am in a GREAT hurry and can't provide further detail for now... sorry
That's a bug in their makefiles then. Put quotes around
$(COMPILER_VERSION).
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
n function exits with code 0 if the result is correct.
>
> I believe this is what causes Debian Bug#185973.
>
Coincidentally, I believe that Falk Hueffner fixed this in the GCC
source very recently. Just FYI.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
' directive does not in itself determine whether that
header will appear in `-MM' dependency output. This is a slight
change in semantics from GCC versions 3.0 and earlier.
If you change -I to -isystem, then the right thing should happen; not
sure about that though.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
On Wed, Mar 26, 2003 at 09:09:39PM +0100, Diether Knof wrote:
> On Wed, Mar 26, 2003 at 10:29:51AM -0500, Daniel Jacobowitz wrote:
> > On Wed, Mar 26, 2003 at 01:31:28PM +0100, Diether Knof wrote:
> > > Package: gcc-3.2
> > > Version: 3.2.1-0pre3
> > >
> >
I just tested this with gcc-snapshot (version 20030314-1), and the
problem compiling blas still seems to exist there.
--
Daniel Schepler "Please don't disillusion me. I
[EMAIL PROTECTED]haven't had breakfast yet."
-- Orson Scott Card
ere?
I don't know if this is the problem or not, but you should kill the
-I/usr/include. Specifying that manually is almost always wrong.
--
Daniel Jacobowitz Debian GNU/Linux Developer
MontaVista Software Carnegie Mellon University
ibrary.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
ive.
Someone may wish to package it separately.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
hat9's 2.4 Ingo's backport patch.
> > BTW, I use the latest kernel on my some machines, so it's not problem
> > for me.
>
> I keep wondering why it's not been accepted upstream. I don't follow
> Linux kernel development anymore, so I don't know the story.
Because 2.4 is a maintenance line, and the patch is gigantic.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
1 - 100 of 400 matches
Mail list logo
