Bug 614293 - gcc -E -nostdinc now aborts on references to standard header files
Summary: gcc -E -nostdinc now aborts on references to standard header files
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc   
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL: http://koji.fedoraproject.org/koji/ta...
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-14 03:18 UTC by Tom Lane
Modified: 2013-07-03 03:31 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-07-14 13:41:16 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Tom Lane 2010-07-14 03:18:04 UTC
Description of problem:
mysql is failing to build in rawhide, as shown at the koji task mentioned in URL.  (The identical sources build fine in F-13.)  Investigation shows that the problem is here:

# gcc -E -nostdinc -dI -I./include -I./include/mysql -I./sql -I./include -I./include/mysql -I./sql include/mysql.h
# 1 "include/mysql.h"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "include/mysql.h"
# 47 "include/mysql.h"
#include <sys/types.h>
include/mysql.h:47:23: fatal error: sys/types.h: No such file or directory
compilation terminated.

Now, /usr/include/sys/types.h is definitely there, so the error message is a bit bogus in any case.  But the real problem is that this is a change from longstanding behavior: the mysql makefile is expecting gcc to bleat but keep on processing.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  gcc -E -nostdinc a file that #include's some system header files.
Actual results:
Aborts after seeing #include <whatever>

Expected results:
Should keep on processing the rest of the input.

Comment 1 Jakub Jelinek 2010-07-14 07:50:15 UTC
But you've told gcc that it shouldn't look up files in /usr/include by -nostdinc.
I think it is clearly mysql that has to be fixed up.

For details see http://gcc.gnu.org/PR15638 and http://gcc.gnu.org/PR44836.

No idea why MySQL is trying to do a poor man's ABI check, when much better ABI check is possible (by analyzing the debug info).

OpenSUSE has abi_test.patch in its mysql-community-server-5.1.46-2.15.src.rpm in Factory, which supposedly allows mysql to build with gcc 4.5+:

diff -Naru mysql-5.1.44-bak/include/mysql.h mysql-5.1.44/include/mysql.h
--- mysql-5.1.44-bak/include/mysql.h	2010-02-23 00:31:19.000000000 +0100
+++ mysql-5.1.44/include/mysql.h	2010-02-23 10:51:49.000000000 +0100
@@ -44,7 +44,9 @@
 #ifndef _global_h				/* If not standard header */
-#include <sys/types.h>
+#ifndef _abi_test_
+#include <sys/types.h>
 #ifdef __LCC__
 #include <winsock2.h>				/* For windows */
diff -Naru mysql-5.1.44-bak/include/mysql.h.pp mysql-5.1.44/include/mysql.h.pp
--- mysql-5.1.44-bak/include/mysql.h.pp	2010-02-23 00:31:19.000000000 +0100
+++ mysql-5.1.44/include/mysql.h.pp	2010-02-23 10:54:46.000000000 +0100
@@ -1,4 +1,3 @@
-#include <sys/types.h>
 typedef char my_bool;
 typedef int my_socket;
 #include "mysql_version.h"
diff -Naru mysql-5.1.44-bak/Makefile.am mysql-5.1.44/Makefile.am
--- mysql-5.1.44-bak/Makefile.am	2010-02-23 00:31:18.000000000 +0100
+++ mysql-5.1.44/Makefile.am	2010-02-23 10:50:18.000000000 +0100
@@ -321,7 +321,8 @@
 	                  -I$(top_builddir)/include \
 	                  -I$(top_builddir)/include/mysql \
 	                  -I$(top_builddir)/sql \
-	                                 $$file 2>/dev/null | \
+ 	                  -D_abi_test_ \
+	                                 $$file | \
 	                  @SED@ -e '/^# /d' \
 	                            -e '/^[ 	]*$$/d' \
 	                            -e '/^#pragma GCC set_debug_pwd/d' \

Comment 2 Tom Lane 2010-07-14 13:41:16 UTC
Hm, given the discussion in PR15638 it seems clear that gcc upstream won't be interested in undoing this change.  I'll whack mysql instead.  Thanks for the pointer to a fix approach.

Comment 3 Tom Lane 2010-07-14 13:50:11 UTC
For the benefit of anyone else researching this issue: turns out mysql is already dealing with this at
and the planned fix looks pretty similar to that shown above.

Comment 4 Tom Lane 2010-07-14 13:52:03 UTC
Oops, that URL should be http://bugs.mysql.com/bug.php?id=52514

Note You need to log in before you can comment on or make changes to this bug.