Re: GCC 3.2.3 Linker error while compiling appz using <errno.h> (maybe glibc error)

[Radosław Ejsmont <rejsmont at rejsmont dot eu dot org>]

Well, it appears, that we have misunderstood. In an issue I've found
<errno.h> _IS_ included, but indirectly, ie. in other header file that
_IS_ included into a certain .c file.

For example, simple code listing:

something.h:
[...]
#include <errno.h>
[...]

myapp.h
[...]
#include "something.h"
[...]

myapp.c
[...]
#include <stdio.h>
#include "myapp.h"
[...]
int a_function_using_errno (void)
{
 perror("Sytem error [%i]",errno);
}
[...]

In this case, LINKER will exit 1 with a message, that undefined
reference to 'errno' was found, while compiler simply ignores this.

It means (for me), that something wrong is NOT with the code, but with
linker or linked libary.

Since I had no opportunity to test it any further, I decided to inform
you about this issue, which has also been reported by some of my
friends. In all of cases I met, this issue appeared after last upsate of
GCC and glibc. Since both packaged were updated an the same time, I
cannot say fot sure if it is an issue in GCC or in glibc.

But as this issue comes only with <errno.h>, so currently I think it is
a matter of the errno.h file in glibc libary. Before update of both
glibc and gcc, everything seemed to compile fine, but after update many
of source packages simply failed to compile. When, for example, qmail
does not want to compile since gcc and glibc update, something must have
gone wrong with gcc or (more possibly) glibc.

Moreover, this appeared to be very location-specyfic. Of course,
<errno.h> or header file that already includes <errno.h> is included far
before call to errno. But still diffenrence of one (even blank !!!) line
make the file compile or not.

I've tried to mirror a buggy system to other box and (sic!) issue has
disappeared, while afted mirroring it once again to third box (that will
be really funny) identical with the second one, issue has came back :)

I have no idea on backgroung of this issue. Many of my friends has
reported this strange behaviour of GCC and it's unknown background.
Maybe it's a matter of sun activity or something like this, but I doubt
:)

Regards,

Radoslaw Ejsmont

-- 
  _________________________________________________________
 /                 *** Radoslaw Ejsmont ***                \
 \               <rejsmont@rejsmont.eu.org>                /
 /=========================================================\
 \     ICQ#: 264814098; GG#: 1282983; IRCname: Bugsik      /
 /             WEBsite: http://rejsmont.eu.org             \
 \    A427 661E 7F0D EA62 F440 BD4E D384 D174 9228 6D81    /
 /                                                         \
 \____________________________________________ArcAngel@UHE_/


> -----Wiadomość oryginalna-----
> Od: Jim Wilson [mailto:wilson@specifixinc.com] 
> Wysłano: 30 listopada 2003 01:30
> Do: rejsmont@rejsmont.eu.org
> DW: gcc-bugs@gcc.gnu.org
> Temat: Re: GCC 3.2.3 Linker error while compiling appz using 
> <errno.h> (maybe glibc error)
> 
> 
> Radosław Ejsmont wrote:
> > This can be easly fixed in compiled application by 
> supplying errorous file with #include <errno.h> however this 
> is just a temporary fix letting you complite desired 
> application. GCC or GLIBC still has this error.
> 
> This is not a gcc bug.
> 
> The C language standard says that errno is specified by 
> errno.h, and it 
> may be a macro or an identifier.  Thus for valid C, you must include 
> errno.h before using errno.
> 
> Also, this is a library implementation issue not a gcc issue.  Some C 
> libraries will work even if errno.h is not included.  glibc won't, 
> because glibc defines it to be a macro.
> -- 
> Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
> 
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature