would be useful. The libc behavior is an
implementation detail.
--
Daniel Jacobowitz
CodeSourcery
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Thu, May 01, 2008 at 10:39:24AM -0500, Jason Kraftcheck wrote:
Daniel Jacobowitz wrote:
On Wed, Apr 30, 2008 at 05:51:32PM -0500, Jason Kraftcheck wrote:
Why can't I take a reference to an rvalue?
Because you can't modify rvalues. This is the definition of the C++
language. The next
to refuse this. The result of a cast
is an rvalue, so you can not take a reference to it.
--
Daniel Jacobowitz
CodeSourcery
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
is not
possible here.
--
Daniel Jacobowitz
CodeSourcery
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
the Texinfo documentation. Accordingly
it is covered by the same license. I don't know what the status of
invariant sections in it is.
--
Daniel Jacobowitz
CodeSourcery
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
section of the GCC
manual page, when it isn't included?
--
Daniel Jacobowitz
CodeSourcery
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Fri, May 11, 2007 at 02:38:57PM +0200, Matthias Klose wrote:
Daniel Jacobowitz writes:
Sorry I don't think I highlighted the bit I meant.
On Fri, May 11, 2007 at 02:28:06PM +0200, Matthias Klose wrote:
ware Foundation; with the Invariant Sections being GNU General
On Mon, May 07, 2007 at 12:23:20PM +0200, Matthias Klose wrote:
I see the same behaviour with the gcc-snapshot package.
So it seems. PR 31900 now.
--
Daniel Jacobowitz
CodeSourcery
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
Package: gcj-4.1
Version: 4.1.2-4
Severity: normal
I recently upgraded gcj (and/or ecj?) and now a couple of GDB tests fail.
To see the problem, take this file:
public class jmain
{
public static void main (String[] args)
{
return;
}
}
[EMAIL
the changelog that it would be using both, but that
doesn't seem to be the case.
I think it's just a bug in readelf that it can't deal with the gnu hash.
IIRC it was fixed recently upstream.
--
Daniel Jacobowitz
CodeSourcery
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
Package: libgnat-4.1
Version: 4.1.1-19
Followup-For: Bug #401385
Some GDB tests in HEAD are now affected by this problem. From Joel
Brobecker at AdaCore:
I have now checked in a patch in GCC that explains that the GNAT
runtime should not be stripped. Would you mind filing a bug with
the
: Invalid argument No stacktrace available
suihkulokki .
Where do we go from here? If the patch is still an improvement, I'd
suggest including it; I'm not going to have another day to figure out
what's wrong with gjdoc for a while.
--
Daniel Jacobowitz
CodeSourcery
--
To UNSUBSCRIBE, email
not sure there's any point submitting it upstream
until the ARM libffi bits go; not sure what status on that is.
--
Daniel Jacobowitz
CodeSourcery
diff -Nur debian.orig/patches/libjava-sjlj.dpatch
debian/patches/libjava-sjlj.dpatch
--- debian.orig/patches/libjava-sjlj.dpatch 1969-12-31 19:00
Package: gcc-4.1
Version: 4.1.1-14
Severity: normal
The latest SVN update pulled in this patch:
2006-09-10 Roger Sayle [EMAIL PROTECTED]
Nicolas Setton [EMAIL PROTECTED]
Backport from mainline
* dwarf2out.c (convert_cfa_to_fb_loc_list): Handle DW_CFA_set_loc.
./libgcc_s.so.1.tmp does not
Looks like you're using an installed crti.o. I bet that's not built
with VFP. You might want to look into e.g. crosstool; it knows how to
bootstrap a toolchain with particular options.
--
Daniel Jacobowitz
CodeSourcery
in the wrong folder).
Right now it's in ports/sysdeps/mips/preconfigure. See the switch on
config_os.
--
Daniel Jacobowitz
CodeSourcery
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
.
Comments?
There are already triplets for this ;-) Take a look at the glibc
configuration; I believe you'd want mips64-linux-gnuabi64 et al.
--
Daniel Jacobowitz
CodeSourcery
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
the o32 case, then use mips-linux-gnu for
that.
--
Daniel Jacobowitz
CodeSourcery
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
it the right way on mips ?
Please see #346346. mips requires -lpthreads
Despite the discussion in that bug, -pthread is supposed to work and
should be fixed.
--
Daniel Jacobowitz
CodeSourcery
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
++, 1, 1, 0, 32 },
++{ GPLUSPLUS_INCLUDE_DIR / TARGET64_MACHINE, G++, 1, 1, 0, 64 },
++#endif
Do you have any evidence that this is necessary? Why? The 64-bit C++
headers work perfectly fine for the 32-bit target, at least - I've
tested that.
--
Daniel Jacobowitz
CodeSourcery, LLC
-littlemips ecoff-bigmips
elf64-tradlittlemips
make[5]: *** [64/libgcc.a] Error 1
Hm, this looks like the mips*-linux ar fails to handle 64bit archives.
IIRC the fix is to just turn off ecoff support. The way archive
formats are detected is a bit ad-hoc...
--
Daniel Jacobowitz
CodeSourcery, LLC
,
often desirable.
dpkg-cross shouldn't need to convert library packages. The same
packages that would be used on a native build are used; they'll be
Architecture: i386, even if they contain amd64 binaries, et cetera for
other platforms.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE
from what dpkg does, and today
dpkg uses libc6-dev-amd64.
However, at the moment, this patch makes it possible to build at least a
plain cross-compiler for such architectures.
I think it's worth doing it correctly.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL
using the compilers as-is.
Anyway, it's up to Matthias. I don't do any work on Debian's gcc
packaging so I don't get to bitch.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
to debug this
for you; I have lots of practice debugging ld.so. Is this really the
main bug at this point? I.E. multigot binaries not working rather than
not linking?
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble
On Sat, Oct 08, 2005 at 09:11:05PM +0200, Thiemo Seufer wrote:
Daniel Jacobowitz wrote:
[snip]
- MultiGOT works fine, until the limit of 16k _dynamic_ symbols is
hit. A executable/library with larger exported GOT will build
without warning but will cause ld.so to segfault
. No one else has been
interested in working on this stuff in the past.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
is completely wrong. I
recall explaining this to you yesterday.
It's a lot of work to fix and no one has done it. That's not the same
thing at all.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
don't know enough about
C++ to explain why, but you can find a number of explanations in the
gcc list archives.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
in the WG notes.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
to be transitional, anyway. In your opinion,
should we fix it, or should we remove it and make the affected library
packages build biarch on i386? I believe that's just glibc, ncurses, and
libbz2 (plus linux-kernel-headers). Ncurses and glibc already support
biarch builds.
--
Daniel Jacobowitz
property, not a compile time one. Runtime tests
are seriously unwise in autoconf, though, so a compiler check is
probably OK. For instance, on MIPS the linker may be built with TLS
support but the kernel may be missing the relevant trap handler.
--
Daniel Jacobowitz
CodeSourcery, LLC
with __thread are not local to the thread.
Test case?
Also, note that this is an unsound way to test for TLS. The compiler,
assembler, linker, C library, and on some platforms kernel must all
support it.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
/bugzilla/show_bug.cgi?id=14884, an
ice-on-valid-code, regression from 3.3.2 and 3.4.0 (fixed in
3.4.3), seen on a ppc64-linux compiler generating 32bit code.
Maybe Dan Jacobowitz could comment on this one.
You must have meant some other PR number? 14884 is a fixincludes thing.
--
Daniel
On Sun, May 15, 2005 at 12:04:02AM +0200, Matthias Klose wrote:
Daniel Jacobowitz writes:
On Sat, May 14, 2005 at 10:52:23PM +0200, Matthias Klose wrote:
Content-Description: message body text
I'm proposing the following updates for gcc-3.3 for testing:
gcc-3.3 (1:3.3.5-13) testing
but not all apps
* set it, so we don't rely on it now (and in fact we need
* to save restore VSCR even if VRSAVE == 0). -- paulus
So if you insist that GCC needs to fiddle the register, when nothing is
looking at it, you'll need some better reason why.
--
Daniel Jacobowitz
the maintainer or the bug submitter.
And he only closed the copy cloned onto gcc-3.4, which he maintains.
Your point is, what, exactly?
--
Daniel Jacobowitz
On Mon, Jan 03, 2005 at 03:22:59AM +0200, Martin-Éric Racine wrote:
On Sun, 2 Jan 2005, Daniel Jacobowitz wrote:
On Sun, Jan 02, 2005 at 11:28:00PM +0200, Martin-Éric Racine wrote:
reopen 288191
thanks
On Sun, 2 Jan 2005, Debian Bug Tracking System wrote
can't link libc statically to a dynamic
executable.
--
Daniel Jacobowitz
in
HEAD?
IIRC, likely branches are deprecated in the latest MIPS ISAs; we
shouldn't be introducing more of them. I don't know what silicon bug
you're working around, though, so I don't know if there's a better way.
--
Daniel Jacobowitz
On Wed, Oct 27, 2004 at 07:09:49PM +0200, Thiemo Seufer wrote:
Daniel Jacobowitz wrote:
[snip]
The appended patch fixes it. It also changes the branch to the likely
variant, this works around some breakage in early R1 silicon.
The patch is against gcc-3.3, newer gccs have the same
On Wed, Oct 27, 2004 at 07:45:40PM +0200, Thiemo Seufer wrote:
Daniel Jacobowitz wrote:
[snip]
IIRC, likely branches are deprecated in the latest MIPS ISAs; we
shouldn't be introducing more of them. I don't know what silicon bug
you're working around, though, so I don't know
On Mon, Oct 25, 2004 at 08:02:37AM +0200, Andreas Jochens wrote:
On 04-Oct-24 18:34, Daniel Jacobowitz wrote:
On Sun, Oct 24, 2004 at 11:08:22PM +0200, Andreas Jochens wrote:
The '/lib64' directory is just ugly and I want to get rid of that
or at least minimize its use (and I think I am
ABI
documentation showing that this is the way to go. That's where you
should start.
Please, tell me - has anyone discussed this compatibility issue outside
of Debian?
--
Daniel Jacobowitz
(), , ||, ?:, and comma operators), the order of
evaluation of subexpressions and the order in which side
effects take place are both unspecified.
I don't have ISO C++ handy but I believe it is worded similarly.
--
Daniel Jacobowitz
a question of precedence, which only affects the way an
expression is interpreted. It's strictly a problem of evaluation
order. Precedence determines how the expression is parsed, i.e.
(-X()) + Y() vs (-X() + Y) () an so forth.
--
Daniel Jacobowitz
However, Linux puts this in
/lib64/ld-linux-x86-64.so.2
Debian should not have a different ABI than the rest of the planet.
If you want it to live in /lib, talk to other distributions about
switching to /lib/ld64.so.1 instead.
--
Daniel Jacobowitz
On Sun, Oct 24, 2004 at 11:08:22PM +0200, Andreas Jochens wrote:
On 04-Oct-24 16:26, Daniel Jacobowitz wrote:
I am aware that the amd64 port has decided to completely ignore
standard methods of handling the multi-arch issues. However, most of
the other changes are compatible as long
On Mon, Oct 04, 2004 at 11:29:58AM -0700, Steve Langasek wrote:
On Mon, Oct 04, 2004 at 09:20:14AM -0400, Daniel Jacobowitz wrote:
On Fri, Sep 24, 2004 at 03:44:39PM -0700, Steve Langasek wrote:
Package: gcc-3.3
Version: 1:3.3.4-12
Using this version of gcc-3.3, trying to combine
or not?
no that's another issue. independently of symlinks things should be
transformed from /usr/lib/. to /usr/lib, /usr/lib/../lib to /usr/lib
I see these kind of pathes generated by the biarch setups for gcc, but
cannot actually tell, how to avoid them.
You basically can't.
--
Daniel
able to deduce (and the documentation
doesn't list any).
It isn't correct. Use a union; you're violating the strict-aliasing
rules.
--
Daniel Jacobowitz
On Sat, Aug 21, 2004 at 02:27:17PM -0500, Matthew Dempsky wrote:
Daniel Jacobowitz [EMAIL PROTECTED] writes:
On Sat, Aug 21, 2004 at 12:44:03AM -0500, Matthew Dempsky wrote:
No warning, but the generated code seems incorrect (or at least a
regression from 3.3) unless ((int *)val)[x] isn't
On Wed, Aug 04, 2004 at 12:33:01PM +0200, Andreas Metzler wrote:
Possible solutions:
1) Delay gcc-3.3's entry into sarge by making it Depend on binutils
2.15.
For the record, I consider this to be the better idea.
--
Daniel Jacobowitz
the GCC work and ask
Matthias to commit it to the gcc-3.4 repository. I understand that it's
very late to be doing this, but I think the changes to gcc-3.4 are safe
and better than attempting to generate another compiler package.
--
Daniel Jacobowitz
are base or standard so there is no must be today
rush. But it still needs to be rushed a bit.
Do you need gcc 3.3?
--
Daniel Jacobowitz
in unstable later.
--
Daniel Jacobowitz
On Sat, Jun 26, 2004 at 07:42:19AM +0200, Matthias Klose wrote:
Daniel Jacobowitz writes:
On Tue, Jun 22, 2004 at 12:51:41PM +0200, Daniel Bonniot wrote:
Thanks for your prompt answer.
yes, space bandwidth. the packages get 100%-200% bigger. and if you
really want to debug gcc
.
--
Daniel Jacobowitz
On Fri, Apr 30, 2004 at 07:43:23PM +0200, Florian Weimer wrote:
Daniel Jacobowitz [EMAIL PROTECTED] writes:
The soname of libstdc++ changed upstream from 3.3. and 3.4, and the
compiler implements a somewhat different flavor of C++ (it's much
closer to the standard now).
However
implemented in both
3.3 and 3.4, I don't think a transition is actually necessary - I
believe things will work OK with both versions linked in. For most
architectures, at least.
Do you have some reason to think this is wrong?
--
Daniel Jacobowitz
MontaVista Software Debian GNU
if that's it.
Correct. It's a parameter name in two or so function prototypes in
pthread.h in woody's glibc. Fixincludes fixes this, but Debian doesn't
package the fixed includes (wisely).
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
.
He's either using too old a linux-kernel-headers package, or kernel
headers which can not be used from userspace. This has nothing to do
with gcc.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
how easily you can build 64-bit gcc with the current
packaging, without a 64-bit glibc. I imagine we try to build both
shared libgcc's which will fail. Let's wait on this until after sarge.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
On Fri, Mar 12, 2004 at 11:34:32AM +, Will Newton wrote:
2. Will the changes to the MIPS ABI[1] in gcc 3.4 require any
transition plan?
Probably not. For o32 - all Debian MIPS ports right now are still o32
- the changes are only in very rare corner cases.
--
Daniel Jacobowitz
MontaVista
20040125 (prerelease) (Debian)
Note the discrepancy. I suggest double-checking what you're actually
running, since g++ 3.3.3 should not search a dir named 3.3.2.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
to run. The section occu- pies no file space, as
indicated by the section type, SHT_NOBITS .
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
aliasing for a
number of good discussions of the problem.
gcc warn about:
test.c: In function `test':
test.c:14: warning: dereferencing type-punned pointer will break
strict-aliasing rules
Is it related?
Yes.
--
Daniel Jacobowitz
MontaVista Software Debian
thought
it might be useful to report it.
If you do this in a loop does it continue to leak?
The string class does manage a certain amount of memory on its own. I
seem to recall this fooling memory leak analyzers before.
--
Daniel Jacobowitz
MontaVista Software Debian GNU
. Then there's one for MIPS
that also describes -march. And one for x86 that also describes
-march.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
. The patch and some additional information is available at:
http://www.cs.ucsb.edu/~wkr/projects/heap_protection/
Enjoy!
--
William Robertson
Reliable Software Group, UC Santa Barbara
http://www.cs.ucsb.edu/~wkr/
--
Daniel Jacobowitz
MontaVista Software Debian GNU
.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
(code, TREE_TYPE (exp), t1, t2);
- }
- return exp;
-}
-
-}
/* Construct, lay out and return the type of methods belonging to class
BASETYPE and whose arguments are described by ARGTYPES and whose values
Jakub
- End forwarded message -
--
Daniel Jacobowitz
,
you should change the Architecture field accordingly. This is in the
Policy 5.6.7
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture
In what way does the architecture for gcj affect the architecture for
classpath? Just set that.
--
Daniel Jacobowitz
MontaVista
On Tue, Sep 23, 2003 at 06:52:43PM -0500, Adam Majer wrote:
On Tue, Sep 23, 2003 at 04:44:16PM -0400, Daniel Jacobowitz wrote:
On Tue, Sep 23, 2003 at 11:51:03AM -0500, Adam Majer wrote:
On Tue, Sep 23, 2003 at 11:00:11AM +0200, Matthias Klose wrote:
Adam Majer writes:
Ok
.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
On Fri, Sep 19, 2003 at 11:52:50AM -0500, Andrés Roldán wrote:
Daniel Jacobowitz [EMAIL PROTECTED] writes:
On Thu, Sep 18, 2003 at 06:17:42PM -0500, Andrés Roldán wrote:
Package: gcc-3.3
Version: 1:3.3.2-0pre3
Severity: normal
Tags: upstream
When trying to executing a binary
libraries. Use GCC. If you say:
gcc -shared -Wl,-soname,libevl.so.1 -o libevl.so blah.os blah.os
Then gcc will do the right thing with -lc, -lgcc_s, and the appropriate
CRT files - that shared library is missing crti.o and crtn.o for
instance, which could cause problems with constructors.
--
Daniel
upstream.
2003-09-17 Daniel Jacobowitz [EMAIL PROTECTED]
* config/rs6000/sysv4.h (LIB_LINUX_SPEC): Make -pthread apply
to shared libraries.
Index: sysv4.h
===
RCS file: /big/fsf/rsync/gcc-cvs/gcc/gcc/config/rs6000
On Wed, Sep 17, 2003 at 09:44:40AM -0400, Daniel Jacobowitz wrote:
On Mon, Sep 15, 2003 at 05:33:36PM +0200, Marcin Owsiany wrote:
Package: gcc-3.3
Version: 1:3.3.2-0pre3
Severity: important
I use -Wl,-z,defs as sugegsted by the Policy.
[EMAIL PROTECTED]:~$ uname -a
Linux
On Mon, Sep 15, 2003 at 02:59:28PM +0100, Joseph S. Myers wrote:
On Sun, 14 Sep 2003, Daniel Jacobowitz wrote:
On sid, I recommend installing flex-old.
I observed previously that for other reasons the old version is also
required for the release manager to use when building release
(I tried cd gcc/gcc cat .cvsignore | xargs rm as suggested by the
response message but that didn't help.)
I'm using debian sid with:
(host) gcc (GCC) 3.3.2 20030831 (Debian prerelease)
flex 2.5.31
On sid, I recommend installing flex-old.
--
Daniel Jacobowitz
MontaVista Software
worked to minimize the testcase. I believe both symptoms
are related to the same underlying cause.
Reproduced. The bug occurs between the 00.rtl and 01.sibling dumps
(). Let me built a couple of CVS gccs to test.
--
Daniel Jacobowitz
MontaVista Software Debian GNU
-0pre1 GCC support library
-- no debconf information
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
before raising this discussion
again. It had nothing at all to do with optimization, either ours or
theirs.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
(and potentially confusing) to have to make
the link yourself. Are the various gcc-* packages going to be put into
the /etc/alternatives system? Well I just wanted to make sure
people were aware of this problem.
If you want a /usr/bin/g++, you're supposed to install the g++
package.
--
Daniel
Right now, if you upgrade gcc-3.3 from 3.3 to 3.3.1, you can end up with a
broken g++ - it will still search for triplet/3.3/crtbeginS.o instead of
3.3.1/crtbeginS.o. I have the feeling that g++-3.3 should depend on
precisely the same version of gcc-3.3...
--
Daniel Jacobowitz
MontaVista
!
I'll take a look at the code and see if I can come up with a fix,
assuming this hasn't already been addressed upstream.
This is just an off-the-cuff answer, but I believe it has been, and
sometime within the last month. I remember seeing a post about a
hardcoded lr...
--
Daniel Jacobowitz
proftpd cvs tree:
I'm pretty sure that naming functions log and logf is actually invalid
C. They're both specified as reserved names in the standard (7.1.3 #1
in C99).
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
of objects in the
same directory.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
:
[EMAIL PROTECTED]:~% gcc-3.2 -Wall -Wconversion -c c.c
c.c: In function `main':
c.c:8: warning: passing arg 1 of `a' as unsigned due to prototype
c.c:8: warning: negative integer implicitly converted to unsigned type
?
It's not part of -Wall because it's too noisy.
--
Daniel Jacobowitz
MontaVista
On Fri, Apr 25, 2003 at 08:40:11PM +0200, Robert Millan wrote:
On Fri, Apr 25, 2003 at 02:18:18PM -0400, Daniel Jacobowitz wrote:
Is this roughly what you want:
[EMAIL PROTECTED]:~% gcc-3.2 -Wall -Wconversion -c c.c
c.c: In function `main':
c.c:8: warning: passing arg 1
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
to package it separately.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
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
' 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
When I use gcc-3.2 with the -MM option
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
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 version
1 - 100 of 195 matches
Mail list logo
