ssett / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

mingw with gcc-4.8 with c++ threads is unable to build gperftools #592

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. download x32-4.8.1-release-posix-sjlj-rev5.7z (mingw, gcc 4.8.1, pthread for 
std::thread functions)
2. configure, remove #undef HAVE_PTHREAD from mingw.h
3. make

What is the expected output? What do you see instead?
error, see below

What version of the product are you using? On what operating system?
gperftools-2.1

Please provide any additional information below.
Compile error:
In file included from 
e:\mingw\lib\gcc\i686-w64-mingw32\4.8.1\include\c++\i686-w64-mingw32\bits\gthr-d
efault.h:35:0,
                 from e:\mingw\lib\gcc\i686-w64-mingw32\4.8.1\include\c++\i686-w64-mingw32\bits\gthr.h:148,
                 from e:\mingw\lib\gcc\i686-w64-mingw32\4.8.1\include\c++\ext\atomicity.h:33,
                 from e:\mingw\lib\gcc\i686-w64-mingw32\4.8.1\include\c++\bits\basic_string.h:39,
                 from e:\mingw\lib\gcc\i686-w64-mingw32\4.8.1\include\c++\string:52,
                 from ./src/gperftools/malloc_extension.h:52,
                 from src/internal_logging.cc:43:
e:\mingw\i686-w64-mingw32\include\pthread.h:245:36: error: new declaration 'int 
sched_yield()'
 int WINPTHREAD_API sched_yield(void);
                                    ^
In file included from ./src/windows/mingw.h:65:0,
                 from ./src/config.h:285,
                 from src/internal_logging.cc:33:
./src/windows/port.h:169:13: error: ambiguates old declaration 'void 
sched_yield()'
 inline void sched_yield(void) {
             ^
In file included from 
e:\mingw\lib\gcc\i686-w64-mingw32\4.8.1\include\c++\i686-w64-mingw32\bits\gthr.h
:148:0,
                 from e:\mingw\lib\gcc\i686-w64-mingw32\4.8.1\include\c++\ext\atomicity.h:33,
                 from e:\mingw\lib\gcc\i686-w64-mingw32\4.8.1\include\c++\bits\basic_string.h:39,
                 from e:\mingw\lib\gcc\i686-w64-mingw32\4.8.1\include\c++\string:52,
                 from ./src/gperftools/malloc_extension.h:52,
                 from src/internal_logging.cc:43:
e:\mingw\lib\gcc\i686-w64-mingw32\4.8.1\include\c++\i686-w64-mingw32\bits\gthr-d
efault.h: In function 'int __gthread_yield()':
e:\mingw\lib\gcc\i686-w64-mingw32\4.8.1\include\c++\i686-w64-mingw32\bits\gthr-d
efault.h:692:33: error: void value not ignored as it ought to be
   return __gthrw_(sched_yield) ();
                                 ^
make: *** [libtcmalloc_minimal_internal_la-internal_logging.lo] Error 1

Original issue reported on code.google.com by juhasz.l...@gmail.com on 26 Nov 2013 at 10:34

GoogleCodeExporter commented 9 years ago
Thanks for reporting. May I expect hope for a patch for that ? It should be 
relatively easy change to fix that.

Original comment by alkondratenko on 26 Nov 2013 at 10:55

GoogleCodeExporter commented 9 years ago
It is not easy for me. If I changed the declaration at port.h ot inline int 
sched_yield(void) a new error is appeared:
In file included from ./src/windows/mingw.h:65:0,
                 from ./src/config.h:285,
                 from src/internal_logging.cc:33:
./src/windows/port.h:170:12: error: previous declaration of 'int sched_yield()' 
with 'C++' linkage
 inline int sched_yield(void) {
            ^
In file included from 
e:\mingw\lib\gcc\i686-w64-mingw32\4.8.1\include\c++\i686-w64-mingw32\bits\gthr-d
efault.h:35:0,
                 from e:\mingw\lib\gcc\i686-w64-mingw32\4.8.1\include\c++\i686-w64-mingw32\bits\gthr.h:148,
                 from e:\mingw\lib\gcc\i686-w64-mingw32\4.8.1\include\c++\ext\atomicity.h:33,
                 from e:\mingw\lib\gcc\i686-w64-mingw32\4.8.1\include\c++\bits\basic_string.h:39,
                 from e:\mingw\lib\gcc\i686-w64-mingw32\4.8.1\include\c++\string:52,
                 from ./src/gperftools/malloc_extension.h:52,
                 from src/internal_logging.cc:43:
e:\mingw\i686-w64-mingw32\include\pthread.h:245:36: error: conflicts with new 
declaration with 'C' linkage
 int WINPTHREAD_API sched_yield(void);
                                    ^
make: *** [libtcmalloc_minimal_internal_la-internal_logging.lo] Error 1

If I removed this declaration and included pthread.h instead a new error came 
up:
In file included from src/thread_cache.cc:34:0:
src/thread_cache.h: In static member function 'static tcmalloc::ThreadCache* 
tcmalloc::ThreadCache::GetThreadHeap()':
src/thread_cache.h:402:46: error: 'perftools_pthread_getspecific' was not 
declared in this scope
       perftools_pthread_getspecific(heap_key_));
                                              ^
src/thread_cache.h: In static member function 'static tcmalloc::ThreadCache* 
tcmalloc::ThreadCache::GetCacheWhichMustBePresent()':
src/thread_cache.h:412:46: error: 'perftools_pthread_getspecific' was not 
declared in this scope
       perftools_pthread_getspecific(heap_key_));
                                              ^
src/thread_cache.cc: In static member function 'static void 
tcmalloc::ThreadCache::InitTSD()':
src/thread_cache.cc:319:62: error: 'perftools_pthread_key_create' was not 
declared in this scope
   perftools_pthread_key_create(&heap_key_, DestroyThreadCache);
                                                              ^
src/thread_cache.cc: In static member function 'static tcmalloc::ThreadCache* 
tcmalloc::ThreadCache::CreateCacheIfNecessary()':
src/thread_cache.cc:377:50: error: 'perftools_pthread_setspecific' was not 
declared in this scope
     perftools_pthread_setspecific(heap_key_, heap);
                                                  ^
src/thread_cache.cc: In static member function 'static void 
tcmalloc::ThreadCache::BecomeIdle()':
src/thread_cache.cc:413:48: error: 'perftools_pthread_setspecific' was not 
declared in this scope
   perftools_pthread_setspecific(heap_key_, NULL);
                                                ^
In file included from src/thread_cache.cc:34:0:
src/thread_cache.h: In static member function 'static tcmalloc::ThreadCache* 
tcmalloc::ThreadCache::GetThreadHeap()':
src/thread_cache.h:403:1: warning: control reaches end of non-void function 
[-Wreturn-type]
 }
 ^
make: *** [libtcmalloc_minimal_internal_la-thread_cache.lo] Error 1

Original comment by juhasz.l...@gmail.com on 27 Nov 2013 at 9:29

GoogleCodeExporter commented 9 years ago
I'm not realy understand this (from config.log):
configure:17348: checking for the pthreads library -lpthreads
configure:17381: gcc -o conftest.exe -g -O2    conftest.c -lpthreads  >&5
e:/mingw/bin/../lib/gcc/i686-w64-mingw32/4.8.1/../../../../i686-w64-mingw32/bin/
ld.exe: cannot find -lpthreads

because -lpthread the right name and it is working.

Original comment by juhasz.l...@gmail.com on 27 Nov 2013 at 10:05

GoogleCodeExporter commented 9 years ago
Double check that with standalone program. Usually gperftools is not using 
pthreads on windows (including mingw). It's supposed to use win32 API instead.

Original comment by alkondratenko on 27 Nov 2013 at 10:07

GoogleCodeExporter commented 9 years ago
" not using pthreads on windows (including mingw)" usually yes, but this mingw 
is compiled with pthread instead of win32 api, because std::thread functions 
not avalibale in mingw which one was compiled with win32 api.

The std::thread functions in C++11 available in posix mingw:
http://stackoverflow.com/questions/18913542/stdthread-is-not-a-member-of-namespa
ce-std-using-eclipse-kepler-mingw
http://stackoverflow.com/questions/18913542/stdthread-is-not-a-member-of-namespa
ce-std-using-eclipse-kepler-mingw

This mingw:  x32-4.8.1-release-posix-sjlj-rev5.7z
http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.0/32
-bit/threads-posix/sjlj/

"It's supposed to use win32 API instead." I think this not the right way in 
this case.

Original comment by juhasz.l...@gmail.com on 28 Nov 2013 at 9:27

GoogleCodeExporter commented 9 years ago
I've yet to check if it really works but my Debian sid recently got mingw 4.8 
too. With same compilation issues.

I've made some quick hacks and code compiles. Some tests do run (under wine). 
Not sure if it really works. But anyway, I'm attaching my hack.

Original comment by alkondratenko on 30 Nov 2013 at 2:15

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by alkondratenko on 30 Nov 2013 at 2:16

GoogleCodeExporter commented 9 years ago
Sorry, I was busy. I will check it.

But I found some strange thing in config.log:

| /* end confdefs.h.  */
| #include <pthread.h>
| int
| main ()
| {
| pthread_t th; pthread_join(th, 0);
|          pthread_attr_init(0); pthread_cleanup_push(0, 0);
|          pthread_create(0,0,0,0); pthread_cleanup_pop(0);
|   ;
|   return 0;
| }
configure:17712: result: no
configure:17717: checking whether -lpthread saves the day
w1:  -nostdlib -shared -fPIC -Wl,-z,defs -g -O2
w2:  -nostdlib -shared -fPIC -Wl,-z,defs -g -O2
configure:17733: gcc -o conftest.exe -nostdlib -shared -fPIC -Wl,-z,defs -g -O2 
   conftest.c -lpthread   -lc >&5
conftest.c:1:0: warning: -fPIC ignored for target (all code is position 
independent) [enabled by default]
 /* confdefs.h */
 ^
e:/mingw/bin/../lib/gcc/i686-w64-mingw32/4.8.1/../../../../i686-w64-mingw32/bin/
ld.exe: unrecognized option '-z'
e:/mingw/bin/../lib/gcc/i686-w64-mingw32/4.8.1/../../../../i686-w64-mingw32/bin/
ld.exe: use the --help option for usage information
collect2.exe: error: ld returned 1 exit status

All phtread checks were failed, because the -z option. But if I removed the -z 
all test were failed again, because there is no libc.a (-lc) in mingw.

The above sample code compiled success with: gcc conftest.c -lpthread.
So pthread is available in my mingw but configure can't found it.

(unfortunately I don't know how can I compile this test with nostdlib)

Original comment by juhasz.l...@gmail.com on 8 Dec 2013 at 10:57

GoogleCodeExporter commented 9 years ago
So, I can't check it: automake 1.13 is not available under mingw.

It's seems to me there are a lot of bug in the configure script.

Original comment by juhasz.l...@gmail.com on 9 Dec 2013 at 9:43

GoogleCodeExporter commented 9 years ago
I've merged a fix. Thanks for reporting this problem.

Original comment by alkondratenko on 5 Jan 2014 at 2:38