eclarations 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
ror suggests that taking a reference is not
possible here.
--
Daniel Jacobowitz
CodeSourcery
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
d::allocator]
I'm pretty sure GCC is correct 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]
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? C
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
quot;,
How can Funding Free Software be an invariant 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:16:28PM +0200, Matthias Klose wrote:
> Daniel Jacobowitz writes:
> > On Thu, May 03, 2007 at 02:06:38PM -0500, Jordi Gutierrez Hermoso wrote:
> > > So what, exactly, is the status of the GFDL and GCC's manpage? I still
> > > insist that no
e is generated from 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]
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 PROTECTED]:/space/fsf/commit/src/gd
gt;
> I assumed from 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 UNSUBS
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 De
ument <>
.
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 to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
atch. I'm 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
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.
W
On Wed, Mar 22, 2006 at 04:41:34AM +, Martin Michlmayr wrote:
> * Daniel Jacobowitz <[EMAIL PROTECTED]> [2006-01-24 10:10]:
> > > > There are various ways to work around this problem, but i would
> > > > like to know what the real cause is there? Is avahi using
> /usr/src/Debian/gcc-4.0-4.0.3-1/build/gcc/crtendS.o
> /usr/arm-vfp-linux-gnu/lib/crtn.o
> /usr/arm-vfp-linux-gnu/bin/ld: ERROR:
> /usr/src/Debian/gcc-4.0-4.0.3-1/build/gcc/crtbeginS.o uses VFP instructions,
> whereas ./libgcc_s.so.1.tmp does not
Looks like you're
I missed this message (went 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]
alking about 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]
tter way while keeping the scheme relatively simple.
>
> 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]
w
ong or is
> > gcc not hanlding 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
cc.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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
+", 1, 1, 0 },
> ++{ GPLUSPLUS_INCLUDE_DIR "/" TARGET32_MACHINE, "G++", 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++
he
ounds to me like
there's just a few, simple, unpacking-related limitations in dpkg-cross
preventing you from 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
CodeSource
h such hacks in the meantime.
dpkg-cross should presumably not diverge 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
that having a biarch cross compiler is, in fact,
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
x27;s not in the bug
tracking system upstream. That's not the same thing. Who do you think
would fix it? Hint, probably me or Thiemo. 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]
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
> > > withou
t internal GOT
> models are freely mixable.
If you'll give me an explicit testcase, I will volunteer 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 Jacobo
ne.
You don't get the picture. In fact the above 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 PROTE
y
well explained at the bottom of the Rationale in the WG notes.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
s is a correctness fix. I'm afraid I 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]
ve.
This package was meant 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
ou point me to a better way to test for TLS?
TLS can be a runtime 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 t
marked 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 PROTE
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 tes
nt some other PR number? 14884 is a fixincludes thing.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
e 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
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 S
#x27;t.
>
> Matthias, this behavior is WAY out of line. The bug was filled against a
> package for which you are neither 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
e, since libc_p.a is
a static library? You can't link libc statically to a dynamic
executable.
--
Daniel Jacobowitz
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
>
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
t the R10k workarounds, but newer GCC ought to have
the other problem fixed. Is there something wrong with the version 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
I don't understand what that is
supposed to show.
It's been talked to death _in the wrong place_.
> Do you really count this patch as a "radical" departure from a
> standard?
Yes. I do not think the commercial distributions will provide a
symlink for compatibility with Debian, unless there is official 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
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
> > >
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 a
er is not one such.
The ABI specifies:
5.2.1Program Interpreter
There is one valid program interpreter for programs conforming to the
AMD64 ABI:
/lib/ld64.so.1
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
followed if Y depends on X
> or vice-versa.
>
> Blah Now I have to go and rewrite some code...
This isn't 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
tion-
call (), &&, ||, ?:, 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
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
>
> > >
re the dynamic linker is. GCC tells it, but
only if you tell GCC that you're using dynamic linking by not
specifying -static. This isn't the only change - you'll get different
startfiles, for instance, and you may get a different selection of
-lgcc_s/-lgcc/-lgcc_eh.
What are you trying to accomplish by lying to GCC about your link?
--
Daniel Jacobowitz
these kind of pathes generated by the biarch setups for gcc, but
> cannot actually tell, how to avoid them.
You basically can't.
--
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
> >&g
; an alternative that I've been 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 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
one objects I will finish 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
3.4 in unstable later.
--
Daniel Jacobowitz
o who is willing to sponsor the following packages:
>
> kernel-image-2.6.7-amd64
> amd64-libs
> amd64-libs-dev
> gcc-3.3-amd64
> gcc-3.4-amd64
> binutils-amd64
>
> None of those 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
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 & band
but remove .debug_info/.debug_str. That's what
libc6-dbg does now and it's proven useful.
--
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 m
closer to the standard now).
However, with symbol versioning and shared libgcc 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 rea
dn't realize that was the issue 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
gt;
> Does this mean that g++ 3.4 _really_ needs lib6 (>= 2.3.2-ds1) and that
> there is no hope of a correctly working backport? Or is there something
> else I can try?
You could fix the header - it's just that one place that uses the
reserved __thread keyword.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
macro definition. We
> cannot tell without a test case, though; please provide one.
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
I don't know 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 Jaco
g++ --version
> g++ (GCC) 3.3.3 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
zeros when the program begins
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
*)&(x))+1))
You can't do this. I recommend you google for "strict 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
>
ection called "ARM Options". 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
e already aware of it, but I 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 J
RELOAD, and is
> transparent to existing applications.
>
> We would definitely appreciate any feedback and bug reports on the
> code. The patch and some additional information is available at:
>
> http://www.cs.ucsb.edu/~wkr/projects/heap_protection/
>
> Enjoy!
>
&
problem, cannot exec `cc1plus': No such file or directory
> configure:4901: $? = 1
Something, then, is forcing your autoconf script to C++. It won't do
the CPP sanity tests with C implicitly.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
forwarded message -
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
;d be a good start at least.
>
> Can anyone from debian-gcc comment on what Kevin said, please?
This is correct. I believe binutils generates useless TEXTRELs on ARM
(or did?) but that's a binutils bug.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
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
MontaVista Software Debian GNU/Linux Developer
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:
> &g
olfields.html#s-f-Architecture
In what way does the architecture for gcj affect the architecture for
classpath? Just set that.
--
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: nor
libc does not support TLS yet.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
s missing crti.o and crtn.o for
instance, which could cause problems with constructors.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
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.
>
p?&pkg=ekg&ver=1%3A1.2-1&arch=powerpc&stamp=1063289370&file=log&as=raw
You can use -lpthread in the meantime. But here's a patch, also
submitted upstream.
2003-09-17 Daniel Jacobowitz <[EMAIL PROTECTED]>
* config/rs6000/sysv4.h (LIB_LINUX_SPEC): Make -p
patch was
committed... no, doesn't look like it.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
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
cuted more than once the lvalue
> function (qux) more than once, but not endlessly, though I occasionally saw
> this behavior as I 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.siblin
> (host) gcc (GCC) 3.3.2 20030831 (Debian prerelease)
> > flex 2.5.31
On sid, I recommend installing flex-old.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
:3.3.2-0pre1 The GNU Compiler Collection (base
ii libc62.3.2-4 GNU C Library: Shared libraries an
ii libgcc1 1:3.3.2-0pre1 GCC support library
-- no debconf information
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
27; token
> $ gcc -o control control.non-standard.c
> $
Why do you believe that this is a bug in GCC? This is a standard
element of C; braces which denote a block scope do not require a
trailing semicolon but other statements do.
Did other versions of GCC accept this?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
> libstdc++5, I'm not ranting on hwmath on sparc (esp. in kernel:), but
> I'm ranting on the common movement to optimize a case and break another.
>
> MfG, JBG
Suggest you read the list archives 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
re supposed to install the "g++"
package.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
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 /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
MontaVist
en gcc is symlinked to a different version) before
> releasing.
You can't use -V between major releases of GCC; in general it just
won't work.
There is no cpp0 any more; it was eliminated entirely.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
; Yes, exactly that. Thanks for isolating this problem!
>
> 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 mo
ings caused by a
> build of the current 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
en relevant. They're files to be used with the set of objects in the
same directory.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
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':
>
o 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 Software Debian GNU/Linux Developer
1 - 100 of 247 matches
Mail list logo
