Josh Stern wrote:
Use of the C99 header in a C library header that
is then used within a C++ program causes compile/linkage
problems. This problem was discovered via failing to compile
small examples using the m_get function in the meschach library
version included in Debian.
This is not a bug.
Jan-Benedict Glaw <[EMAIL PROTECTED]> writes:
> Would Debian accept two ix86 distributions? One i386 and, say, i[56]86?
Most developers probably would, if presented with a sound plan that
makes that happen and has no downsides (except for the obvious one
that ftp archives will need more space).
Jan-Benedict Glaw <[EMAIL PROTECTED]> writes:
> > You are wrong. There are two versions of atomicity.h, one for i486+,
> > and the other for i386+ (at the time the other distributors released
> > their compilers, there was only the i486+ version, and it was assumed
> > to work for i386+, but didn'
Jan-Benedict Glaw <[EMAIL PROTECTED]> writes:
> Am I wrong or did we, "forced" because we wanted to be binary compatible
> to some major distributions, just follow others and doing optimization
> just as they did?
You are wrong. There are two versions of atomicity.h, one for i486+,
and the other
Jan-Benedict Glaw <[EMAIL PROTECTED]> writes:
> Having a "broken" libstdc++ is already bad enough. Please, please please
> please please don't make it worse as it's already today. I heared rumors
> that gcc-3.4 might fix the current situation (wrt. libstdc++).
Don't believe these rumors; they are
Nikita V. Youshchenko wrote:
gcc 3.3 is an update for gcc 3.2, so it fixes bugs reported in gcc.
But what about bugs reported on gcc-3.2?
Why is the answer to that question of any relevance for Debian?
Regards,
Martin
"Nikita V. Youshchenko" <[EMAIL PROTECTED]> writes:
> As gcc changelog.Debian states, bugs filed against earlier versions of gcc
> (e.g. gcc-3.2 or gcc-2.95) are closed when they are fixed in later version
> (e.g. gcc 3.3).
>
> Is that really correct?
> gcc-3.2 package is still in Debian and stil
Falk Hueffner <[EMAIL PROTECTED]> writes:
> This is not the problem. gcc assumes the asm will return the same
> value unless it is explicitely marked "volatile" (or has no oputputs),
> and will happily merge them.
I see. Then this would be a glibc bug, for using __asm__ __volatile__
in __bswap16.
<[EMAIL PROTECTED]> writes:
> As you can see, the branch due to the family is unnecessary. This bug
> exists in gcc272, gcc 2.95 and gcc 3.2
It is unlikely that this bug will ever get fixed, as gcc won't be able
to determine that the two __asm__ blocks really have the same effect.
So if you wan
BjÂÃrn Johansson <[EMAIL PROTECTED]> writes:
> Hello!
>
> I have problems with GCC. I thought that my problems were caused
> by libc, so I upgraded to the latest version(2.3.x), but it made
> no difference, GCC still can't find the required header files when
> I try to compile something. It can't
[EMAIL PROTECTED] (David N. Welton) writes:
> Since I don't have shared libraries, is it ok if I just define it,
> just so it's there?
>
> void* __dso_handle = (void*) &__dso_handle;
That should work, yes.
> BTW, can you also confirm that this is for C++ only?
In GCC, it is for C++ only, yes
David N. Welton wrote:
The problem is that despite using -nostdlib whilst compiling, I still
get __cxa_atexit and __dso_handle defined in my .o files (yes, eCos
utilizes C++ in places).
I think the problem is not that you are getting definitions, but that
you are getting references to these symbol
Peter Hawkins wrote:
I've never touched the locale on my systems, so it's the default (LANG="C"?)
Please invoke locale(1) to be sure.
However, there is still a minor problem in that running the 'java' wrapper
script picks a different default encoding to the default encoding of the jdk.
I gather t
Peter Hawkins <[EMAIL PROTECTED]> writes:
> gcj doesn't appear to like high-valued characters in it's input stream.
Please don't use the term "high ASCII", there is no such thing. Most
likely, you are talking about Latin-1 (but it could also be that you
are talking about UTF-8 or Latin-9).
> Si
Phil Edwards <[EMAIL PROTECTED]> writes:
> > int foo(int *x, int *y)
> > {
> > return x - y;
> > }
>
> There is no conversion to int. foo* may be subtracted from foo* for any
> type foo. It's normal pointer arithmetic. This code is fine.
You are missing the point. The result of the subtr
Fredrick Paul Eisele <[EMAIL PROTECTED]> writes:
> /usr/include/c++/3.2/bits/stl_vector.h:893: no matching function for
> call to `Field::Field(const Field&)'
Are you reporting some kind of bug, or are you merely requesting a new
feature?
If this is a bug report: What is the bug? What is the spe
Heiko Scheit <[EMAIL PROTECTED]> writes:
> I am not sure this is a bug, but I thought that the inheritance should
> work also in this case (i.e. with overloaded functions).
This is not a bug. In standard C++, methods in a derived class hide
methods in the base class. Any C++ book will tell you so
Herbert Valerio Riedel <[EMAIL PROTECTED]> writes:
> ...so... is _still_ not a buggy behaviour??
No. Look at 8.5/9:
# If no initializer is specified for an object, and the object is of
# (possibly cv-qualified) non-POD class type (or array thereof), the
# object shall be default-initialized; if
Adam Heath <[EMAIL PROTECTED]> writes:
> java.net.SocketException: SO_REUSEADDR: not valid for TCP
[...]
> It is perfectly fine to set that option for a tcp socket. Setting it for
> udp makes no sense.
Hmm.
http://java.sun.com/j2se/1.4.1/docs/api/java/net/SocketOptions.html#SO_REUSEADDR
says
S
Sébastien FRANÇOIS wrote:
/usr/bin/tbl: /usr/local/lib/libgcc_s.so.1: version `GCC_3.3' not found
Can you report what package /usr/local/lib/libgcc_s.so.1 belongs to?
Just try removing that file.
Regards,
Martin
Thomas Richter <[EMAIL PROTECTED]> writes:
> g++-3.3 should warn about an object declared as a class that is later
> on used as a "struct". This would simplify the generation of portable
> code as at least one other popular compiler will generate warnings for
> this case that could be easily avoid
Matthias Klose <[EMAIL PROTECTED]> writes:
> Please could you point me to the invariant-section material? Tried to
> find it, but maybe it's too late here in Europe and I'm not awake :-(
cd gcc/doc
grep Invariant *.texi
cpp.texi:This manual contains no Invariant Sections. The Front-Cover Texts a
"Adam Conrad" <[EMAIL PROTECTED]> writes:
> Here you go:
>
> http://people.debian.org/~adconrad/utah-glx/
That appears to be a bug in the build machine installation, then, or
in glibc: invocation
gcc -E conftest.c
should have worked: This *is* the way to invoke the preprocessor.
However, it g
Matijs van Zuijlen wrote:
See `config.log' for more details.
Can you provide the relevant fragment of config.log, for more details?
Regards,
Martin
Package: gcc-defaults
Version: 1.5
Severity: wishlist
According to
http://www.opengroup.org/onlinepubs/007904975/utilities/c99.html
a POSIX system should provide a c99 utility if the "C Languages
Development Utilities" feature is supported.
Regards,
Martin
Matt Zimmerman <[EMAIL PROTECTED]> writes:
> > Is there a cure in sight? Who feels responsible for fixing this bug? I
> > am getting desperate...
>
> I have reassigned the bug to the gcc maintainers, who will evaluate it.
In any case, I suggest to apply a work-around: Fixing the bug may take
da
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> 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.
Most likely: I guess he's picking up the wrong
stddef.h. -I/usr/include/linux should go with it: No user-space
pr
Benjamin Dauvergne <[EMAIL PROTECTED]> writes:
> Could I suggest you to compile GCC with --disable-nls or without
> packaging certain translations like french because they causes bug in
> gcc/g++ when error messages must be printed. It's a known bug in the bug
> database of gcc[1]. With
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> Well, presumably he is linking using gcc to avoid libstdc++; is there
> anything besides the missing library which g++ would change?
Yes, there are minor differences: g++ adds -lm -lgcc_s, gcc adds -lgcc
(or -lgcc_eh). Those shouldn't make a differe
Fernando Sanchez <[EMAIL PROTECTED]> writes:
> I have been suggested to ask for help here; please bounce me
> somewhere else if I am writing to the wrong address. I got a bug reported on
> libsablot0c102 package, which appeared on the migration to gcc-3.2. Do you
> recommend adding -lstdc++,
Matthias Klose <[EMAIL PROTECTED]> writes:
> Rumour says, that there will be one more C++ ABI change to fix bugs
> found after the gcc-3.2 release (maybe for gcc-3.4), and then the C++
> ABI will be stable ...
I believe this is a misprediction of the future. Here is my prediction:
1. The "core"
Miah Gregory <[EMAIL PROTECTED]> writes:
> As such, I've come here in the hope that someone can suggest how I might
> find out the exact cause of the problem, as I've never had to try and track
> down potential compiler bugs before.
Dear Miah,
As a starting point, you have to find precisely out
Anthony DeRobertis <[EMAIL PROTECTED]> writes:
> > The declaration
> >
> > int x[2, 3];
> >
> > is not legal in C99, since "2, 3" is not an assignment-expression.
>
> I'm not a C99 language lawyer, but are you sure? Is the comma operator
> allowed there, or would one have to write "int x[(2,3)]"
Hans Ginzel <[EMAIL PROTECTED]> writes:
> Probably it could be useful for others, but don't know where to post
> it.
This is likely the wrong place. If you want to publish it, you should
best release it as a package of its own, or contribute it to some
existing library package, such as Boost.
Matthias Klose wrote:
Martin, is there anything we can do without further information?
There is clearly a bug in the compiler: the compiler should have
rejected the code in the first place. In
http://gcc.gnu.org/ml/gcc/2002-08/msg00401.html
a patch for this bug is mentioned, but I don't know if a
Matthias Klose wrote:
bug-171561.cc:14: `bin' is not a member of type `std::basic_ios >'
[...]
std::ifstream f (argv[1], ios::bin | std::ios::in);
What gcc is that? I get
a.c:14: `ios' undeclared (first use this function)
If I fix this to read "std::ios::binary", as it should read in C++, I
get
Sorry if this is not a bug, but I cannot find any way why it isn't.
[...]
bin2a.cc: In function `int main(int, char**)':
bin2a.cc:9: `cerr' undeclared (first use this function)
It is not a bug, cerr is really not a predefined identifier in C++. What
you mean is std::cerr.
Regards,
Martin
Junichi Uekawa <[EMAIL PROTECTED]> writes:
> I've thought having a directory for doing LD_LIBRARY_PATH might help
> people keep compatibility with other dists or legacy applications,
>
> thoughts?
I think that should happen on a case-by-case basis, with a bias
towards not providing the library.
Martin Wuertele <[EMAIL PROTECTED]> writes:
> Please include the stack-protector patch from
> http://www.trl.ibm.com/projects/security/ssp/gcc3_2/protector-3.2-5.tar.gz
This wish is unlikely to be implemented. If you want to see this to
become part of Debian gcc, I recommend that you first ask GC
Ben Burton <[EMAIL PROTECTED]> writes:
> I would have expected a compile error, since the declaration
> "Foo bar = foo;" tries to use the non-existant default constructor for
> class Foo.
No, it doesn't. This is not a initialization followed by an assignment
operator; there is no assignment opera
40 matches
Mail list logo
