Bug 49745 - error: ‘int truncate’ redeclared as different kind of symbol
Summary: error: ‘int truncate’ redeclared as different kind of symbol
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.4.5
: P3 normal
Target Milestone: 4.7.0
Assignee: Paolo Carlini
URL:
Keywords:
: 36231 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-07-14 10:28 UTC by Mathieu Malaterre
Modified: 2011-07-15 21:55 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.7.0
Known to fail: 4.6.1
Last reconfirmed: 2011-07-14 10:30:57


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Malaterre 2011-07-14 10:28:46 UTC
Hi,

  g++ pollutes the global namespace. The following does not compile with G++ 4.4.5:


#include <iostream>
int truncate = 0;
int main()
{
  return 0;
}

If fails with:


t.cxx:2: error: ‘int truncate’ redeclared as different kind of symbol
/usr/include/unistd.h:998: error: previous declaration of ‘int truncate(const char*, __off_t)’


Thanks !
Comment 1 Richard Biener 2011-07-14 10:30:57 UTC
Confirmed.
Comment 2 Jonathan Wakely 2011-07-14 10:51:57 UTC
dup of PR 36231 ?
Comment 3 Jonathan Wakely 2011-07-14 11:01:26 UTC
the problem is actually in gthr-posix.h

no libstdc++ header includes <unistd.h> except <ext/stdio_syn_filebuf.h> which is a non-standard extension and so that's not a problem
Comment 4 Jonathan Wakely 2011-07-14 11:13:13 UTC
Why does gthr-posix.h even include <unistd.h>?

--- gcc/gthr-posix.h.orig       2011-07-14 11:09:00.148778460 +0000
+++ gcc/gthr-posix.h    2011-07-14 11:09:01.763786789 +0000
@@ -39,7 +39,6 @@
 #endif

 #include <pthread.h>
-#include <unistd.h>

 typedef pthread_t __gthread_t;
 typedef pthread_key_t __gthread_key_t;


The names from <pthread.h> will still be declared, but that's a LOT better than bringing in everything from <unistd.h>

If some crufty OS needs <unistd.h> it should only be included conditionally
Comment 5 Paolo Carlini 2011-07-14 12:01:40 UTC
Who maintains gthr-posix.h? Indeed, in general, this is a well known issue, can be resolved as dup.
Comment 6 Paolo Carlini 2011-07-14 12:07:45 UTC
Before resolving as dup of 36231, let's add in CC Jakub too, it would be nice if for 4.7 we could finally take the plunge and follow Jon's suggestion, or a variant of it, but I don't know who normally fiddles with the gthr-* headers...
Comment 7 Jonathan Wakely 2011-07-14 12:13:27 UTC
I don't think there is a maintainer for gthreads
Comment 8 Paolo Carlini 2011-07-14 12:30:43 UTC
"Worst" case we can regression test your simple change on Linux (and maybe another target normally using the Posix model, Rainer on Solaris?) and send it out to the mailing list for review. A global maintainer could approve it.
Comment 9 Jakub Jelinek 2011-07-14 12:33:16 UTC
svn blame isn't hard to use.
You'll find out that the unistd.h include was added by
http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01666.html
There are still some of the unistd.h guard macros used in gthr*, so you can't just drop that.  But, two of the three macros are limited to libobjc (the scheduling stuff), so if it wasn't for _POSIX_TIMEOUTS for __gthread_mutex_timedwait, you could guard the unistd.h include with
#if defined(_LIBOBJC) || defined(_LIBOBJC_WEAK)
Unfortunately, the remaining one, _POSIX_TIMEOUTS and defining __gthread_mutex_timedlock if it is present, is used in libstdc++ (<mutex> in particular, and apparently unconditionally there, so it will just not compile on prehistoric OSes which lack pthread_mutex_timedlock or on systems that don't use gthr-posix.h but other gthr-*.h headers instead).
So, if you want to avoid including unistd.h, you'd need to e.g. add some configure test in libstdc++ and in gthr-posix.h use
#if defined(_LIBOBJC) || defined(_LIBOBJC_WEAK) \
    || !defined(_GTHR_HAS_POSIX_TIMEOUTS)
#include <unistd.h>
#ifdef _POSIX_TIMEOUTS
#define _GTHR_HAS_POSIX_TIMEOUTS _POSIX_TIMEOUTS
#endif
#endif
and use _GTHR_HAS_POSIX_TIMEOUTS instead of _POSIX_TIMEOUTS in gthr.h and arrange
for libstdc++ headers to define _GTHR_HAS_POSIX_TIMEOUTS based on whether <unistd.h> defines _POSIX_TIMEOUTS.
Comment 10 Jakub Jelinek 2011-07-14 12:34:32 UTC
BTW, <mutex> really shouldn't be using __gthread_mutex_timedlock if it isn't available...
Comment 11 Paolo Carlini 2011-07-14 12:43:53 UTC
Thanks Jakub. Thus, seems a little more difficult than we hoped, but still doable. We'll give a try to your scheme.
Comment 12 Paolo Carlini 2011-07-14 21:50:25 UTC
Before going ahead as suggested by Jakub, maybe Nicola can double check that libobjc still wants those <unistd.h> includes?
Comment 13 Jakub Jelinek 2011-07-14 21:54:36 UTC
I think only libstdc++ installs the gthr* headers, all other uses inside of gcc just include it in library *.c files rather than headers, so for _LIBOBJC it IMHO shouldn't be harmful if unistd.h is included.
Comment 14 Paolo Carlini 2011-07-14 21:58:55 UTC
Sure Jakub. I was only wondering if maybe, after all these years, turns out that libobjc doesn't really need that include anymore. We could simplify the macros a bit...
Comment 15 Paolo Carlini 2011-07-15 10:24:15 UTC
By the way, Jakub, correct me if I'm wrong and/or remember incorrectly what we decided here at the time, but as far as I can see there is no risk with __gthread_mutex_timedlock, because if it's unavailable, _GLIBCXX_HAS_GTHREADS is undefined and the entire <mutex> ins't available. It can be argued that we should do this in a finer grained way, but that's another issue...
Comment 16 Jakub Jelinek 2011-07-15 10:47:46 UTC
Then you probably could use _GLIBCXX_HAS_GTHREADS as the macro to avoid including unistd.h and assuming that _POSIX_TIMEOUT is defined.
Though perhaps better would be to call it _GTHREADS_ASSUME_POSIX_TIMEOUTS or similar and define it in some libstdc++ headers before including gthr.h.
Comment 17 Paolo Carlini 2011-07-15 10:53:11 UTC
Indeed, I was having the same thought... _GLIBCXX_HAS_GTHREADS is a bit stricter though (doesn't allow 0), but would do. And I agree that in that case we should use another name. Essentially, about the ordering, just double check that, as should normally be, c++config.h is included before anything else.
Comment 18 Paolo Carlini 2011-07-15 12:09:04 UTC
*** Bug 36231 has been marked as a duplicate of this bug. ***
Comment 19 paolo@gcc.gnu.org 2011-07-15 21:52:14 UTC
Author: paolo
Date: Fri Jul 15 21:52:06 2011
New Revision: 176335

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176335
Log:
/gcc
2011-07-15  Paolo Carlini  <paolo.carlini@oracle.com>
	    Jakub Jelinek  <jakub@redhat.com>
	    Jonathan Wakely  <jwakely.gcc@gmail.com>

	PR libstdc++/49745
	* gthr-posix.h: Do not include <unistd.h> unconditionally; use
	_GTHREADS_USE_MUTEX_TIMEDLOCK instead of _POSIX_TIMEOUTS.

/libstdc++-v3
2011-07-15  Paolo Carlini  <paolo.carlini@oracle.com>
	    Jakub Jelinek  <jakub@redhat.com>

	PR libstdc++/49745
	* acinclude.m4 ([GLIBCXX_CHECK_GTHREADS]): Check separately for
	_POSIX_TIMEOUTS and define _GTHREADS_USE_MUTEX_TIMEDLOCK.
	* libstdc++-v3/libsupc++/guard.cc: Include <unistd.h>.
	* testsuite/17_intro/headers/c++1998/49745.cc: New.
	* configure: Regenerate.
	* config.h.in: Likewise.

Added:
    trunk/libstdc++-v3/testsuite/17_intro/headers/c++1998/49745.cc
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gthr-posix.h
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/acinclude.m4
    trunk/libstdc++-v3/config.h.in
    trunk/libstdc++-v3/configure
    trunk/libstdc++-v3/libsupc++/guard.cc
Comment 20 Paolo Carlini 2011-07-15 21:55:38 UTC
Fixed for 4.7.0.