www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2008/06/09/14:49:26

X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
X-Recipient: djgpp-workers AT delorie DOT com
X-Authenticated: #27081556
X-Provags-ID: V01U2FsdGVkX18tRBc9obItuBS3ucPTU2MwqTWTne3GD5IurP5znW
G1Ip7nWFqpuhEU
From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
To: djgpp-workers AT delorie DOT com
Subject: Difficulties compiling emu387.cc with gcc 4.3.0
Date: Mon, 9 Jun 2008 20:58:05 +0200
User-Agent: KMail/1.9.5
MIME-Version: 1.0
Message-Id: <200806092058.05925.juan.guerrero@gmx.de>
X-Y-GMX-Trusted: 0
Reply-To: djgpp-workers AT delorie DOT com

I have tried to compile today's CVS sources and I have run into a problem.
I am using gcc 4.3.0 and bnu217br2.  The sources can only be compiled if
Andris' patches to emu387.cc and ieeefp.h are applied (see 
<http://www.delorie.com/archives/browse.cgi?p=djgpp-workers/2008/05/01/08:49:44>
and
<http://www.delorie.com/archives/browse.cgi?p=djgpp-workers/2008/05/01/09:18:37>).
That is ok and well known.  Now if I apply the following patch:

diff -aprNU3 djgpp.orig/include/string.h djgpp/include/string.h
--- djgpp.orig/include/string.h	2007-12-11 07:01:20 +0000
+++ djgpp/include/string.h	2008-06-09 16:05:26 +0000
@@ -77,6 +77,7 @@ char *  rindex(const char *_string, int 
 char *	stpcpy(char *_dest, const char *_src);
 char *	stpncpy(char *_dest, const char *_src, size_t _n);
 char *	strdup(const char *_s);
+char *	strndup(const char *_s, size_t _n);
 size_t	strlcat(char *_dest, const char *_src, size_t _size);
 size_t	strlcpy(char *_dest, const char *_src, size_t _size);
 char *	strlwr(char *_s);
@@ -84,6 +85,7 @@ int	strcasecmp(const char *_s1, const ch
 int	stricmp(const char *_s1, const char *_s2);
 int	strncasecmp(const char *_s1, const char *_s2, size_t _n);
 int	strnicmp(const char *_s1, const char *_s2, size_t _n);
+size_t	strnlen(const char *_s, size_t _n);
 char *	strsep(char **_stringp, const char *_delim);
 char *	strupr(char *_s);
 

the compilation of emu387.cc fails with the following error message:


../makemake.exe
makemake: scanning libemu for makefiles
C:/djgpp/bin/make.exe -f makefile.sub
C:/djgpp/bin/make.exe -C src 
gcc -MD -O2 -mtune=i586 -march=i386 -Wall  -Wcast-qual -Werror   -Wpointer-arith -Wshadow  -Wwrite-strings -Wundef -Wcast-align -Wsign-compare -nostdinc -iquote . -isystem ../../../include -DGAS_MAJOR=2 -DGAS_MINOR=17 -DGAS_MINORMINOR=0 -c -fno-exceptions emu387.cc
cc1plus.exe: warnings being treated as errors
emu387.cc: In function 'void fsqrt()':
emu387.cc:2366: error: likely type-punning may break strict-aliasing rules: object '*{unknown}' of main type 'long int' is referenced at or around emu387.cc:2366 and may be aliased to object 'result' of main type 'long long unsigned int' which is referenced at or around emu387.cc:2357.
emu387.cc:2371: error: likely type-punning may break strict-aliasing rules: object '*{unknown}' of main type 'unsigned int' is referenced at or around emu387.cc:2371 and may be aliased to object 'val' of main type 'long long unsigned int' which is referenced at or around emu387.cc:2356.
make.exe[3]: *** [emu387.o] Error 1
make.exe[2]: *** [all_subs] Error 2
make.exe[1]: *** [all] Error 2
make.exe: *** [subs] Error 2


Please note that strndup() and strnlen() are neither implemented nor used
anywhere in the complete CVS code.  If I comment out one of the declaration
(no matter which one) the code compiles without error.  As soon as both are
declarations are active again the compilation fails.  If I replace gcc and
gpp 4.3.0 with gcc and gpp 4.2.3 then the sources can be compiled without
any difficulties.  The surprising fact to me is not really  the error message
but the way it is triggered.
Any ideas what I am missing here?  If more information is needed, let me know.

Regards,
Juan M. Guerrero

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019