On Thu, 21 Dec 2000, Mario Torre wrote:
> But that's not important if it works for at least the good code... there is a
> flag to avoid strict ISO compliance with the C++ compiler?
You can try "-fpermissive", but 2.96 with -fpermissive is still stricter
than older versions without it.
> t1.c:25: warning: implicit declaration of function `strlen'
> t1.c:27: warning: implicit declaration of function `strcpy'
Missing include - should include <string.h>
Not critical, it does the right thing nevertheless.
> t4.c:28: warning: implicit declaration of function `exit'
> t4.c:32: warning: implicit declaration of function `strlen'
> t4.c:34: warning: implicit declaration of function `strcpy'
Same here, should include <string.h> and <stdlib.h>
> xlock-exploit.c:58: warning: implicit declaration of function `memset'
> xlock-exploit.c:58: warning: implicit declaration of function `strlen'
Same here (<string.h>)
> exploit-non-exec-stack.c:45: warning: implicit declaration of function `exit'
And <stdlib.h>
> There is not the inclusion for the string.h or the strlib.h, so that warning
> would be normal if the stdio.h avoid to include these libraries, but this is
> not the case.
<stdio.h> doesn't include <string.h> and <stdlib.h>. At least not in glibc
2.2.
> The strange thing is when I call gcc to compile only the t1.c program (as if
> I want ot compile only it, and not the whole library).
> The compilation goes well, without warnigs.
Are you sure you're using the same compiler flags? You don't get these
warnings without the "-Wall" flag.
> Surely, it can be only a matter of ISO compliance:
> The flag "-Wall" may be the reason of these extra warnings, but the egcs or
> the gcc 2.95 if called with the -Wall option gave out no warnings.
Because they're broken.
> Anyway, this mail should be read as: am I free (and safe) to use the new
> version of the compiler, or I will run into problems?
We use it for everything and so far we haven't run into serious problems.
The fact that all the packages in Red Hat Linux 7 and in Rawhide (and
Powertools) are working shows the compiler can't be bad. ;)
I can't guarantee you won't run into problems - I can't guarantee it
either for any other compiler version.
If you do run into problems, make sure you report them
(http://bugzilla.redhat.com/bugzilla) so we can fix them in time for the
next version.
> but there is the need, at least for the next release of RedHat
> Linux, for a _real_ compatible library for programs compiled with at least
> older versions of RedHat Linux
We have those. compat-glibc and compat-libstdc++.
> I used Quanta and KDEStudio, compiled for
> RedHat L. 6.2, and they went in SegFault,
Do you have any details on this (backtrace etc)?
Are they using Qt 1.x or 2.x?
LLaP
bero
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
