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
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
7;t need to be yanked, but the compiler certainly
does.
--
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]
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
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
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
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
/usr/include/g++-v3/bits/locale_facets.tcc: No such file or
> directory.
> in /usr/include/g++-v3/bits/locale_facets.tcc
That's not enough information. How was this built? What libraries is
it really linked to? What headers are really opened during build?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
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
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
> > >
> >
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
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
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':
>
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]
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]
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
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
> /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
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
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
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]
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]
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
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
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
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]
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
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
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
1 - 100 of 247 matches
Mail list logo
