search

lhmouse / mcfgthread

Cornerstone of the MOST efficient std::thread on Windows for mingw-w64
https://gcc-mcf.lhmouse.com/
Other
277 stars 28 forks source link

libobjc not building #6

Closed revelator closed 2 years ago

revelator commented 8 years ago

Gave it a go with a gcc-5.4.0 bootstrap and most of it builds but it keels over on objc it seems.

libtool: link: /f/projects/runtime/_gccbuild32/./gcc/xgcc -B/f/projects/runtime/_gccbuild32/./gcc/ -L/mingw32/i686-w64-mgw32/lib/ -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/i686-w64-mingw32/sys-include -shared .libs/NX/init.o .libs/ivars.o .libs/memory.o .libs/methods.o .libs/nil_method.o .libs/objc-foreach.o .libs/objc-sync.o .libs/obj -shared-libgcc -o .libs/libobjc-4.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libobjc.dll. .libs/thr.o: I funktionen "objc_mutex_allocate": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:260: undefined reference to __gthread_objc_mutex_allocate' .libs/thr.o: I funktionen "objc_mutex_lock": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:316: undefined reference togthread_objc_thread_id' f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:321: undefined reference to __gthread_objc_mutex_lock' .libs/thr.o: I funktionen "objc_mutex_deallocate": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:291: undefined reference togthread_objc_mutex_deallocate' .libs/thr.o: I funktionen "objc_mutex_trylock": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:346: undefined reference to __gthread_objc_thread_id' f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:351: undefined reference to__gthread_objc_mutex_trylock' .libs/thr.o: I funktionen "objc_mutex_unlock": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:378: undefined reference to `__gthread_objc_thread_id' .libs/thr.o: I funktionen "objc_thread_detach":

:/projects/runtime/gcc-5.4.0/libobjc/thr.c:169: undefined reference to __gthread_objc_thread_detach' .libs/thr.o: I funktionen "objc_thread_set_data": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:235: undefined reference togthread_objc_thread_set_data' .libs/thr.o: I funktionen "objc_condition_allocate": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:415: undefined reference to `gthread_objc_condition_allocate' .libs/thr.o: I funktionen "objc_condition_broadcast": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:498: undefined reference to__gthread_objc_condition_broadcast' .libs/thr.o: I funktionen "objc_condition_deallocate": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:439: undefined reference togthread_objc_condition_deallocate' .libs/thr.o: I funktionen "objc_condition_wait": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:465: undefined reference to__gthread_objc_thread_id' f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:478: undefined reference togthread_objc_condition_wait' .libs/thr.o: I funktionen "_objc_init_thread_system": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:78: undefined reference to__gthread_objc_init_thread_system' .libs/thr.o: I funktionen "objc_thread_set_priority": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:189: undefined reference togthread_objc_thread_set_priority' .libs/thr.o: I funktionen "objc_thread_get_priority": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:196: undefined reference to__gthread_objc_thread_get_priority' .libs/thr.o: I funktionen "objc_thread_yield": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:205: undefined reference to__gthread_objc_thread_yield' .libs/thr.o: I funktionen "objc_thread_id": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:227: undefined reference to`gthread_objc_thread_id' .libs/thr.o: I funktionen "objc_thread_set_data": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:235: undefined reference to __gthread_objc_thread_set_data' .libs/thr.o: I funktionen "objc_thread_get_data": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:243: undefined reference togthread_objc_thread_get_data' .libs/thr.o: I funktionen "objc_mutex_unlock": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:391: undefined reference to `gthread_objc_mutex_unlock' .libs/thr.o: I funktionen "objc_thread_exit": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:219: undefined reference to__gthread_objc_thread_exit' .libs/thr.o: I funktionen "objc_condition_broadcast": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:498: undefined reference to__gthread_objc_condition_broadcast' .libs/thr.o: I funktionen "objc_condition_signal": f:/projects/runtime/gcc-5.4.0/libobjc/thr.c:512: undefined reference to__gthread_objc_condition_signal' collect2.exe: error: ld returned 1 exit status make[2]: **\* [libobjc.la] Error 1 make[2]: Leaving directory/f/projects/runtime/_gccbuild32/i686-w64-mingw32/libobjc' make[1]: [all-target-libobjc] Error 2 make[1]: Leaving directory`/f/projects/runtime/_gccbuild32' make: \ [all] Error 2

lhmouse commented 6 years ago

Understandable, this should be the gcc devs job.

Yes and no. As Kai Tietz has retreated from GCC, now Jonathan Yong now is the only maintainer for Cygwin and Mingw-w64. GCC itself has been built by not only maintainers, but contributers. This includes you, me, and everyone else who is willing to contribute. If people contribute something, they deserve it. If people don't contribute something, they don't get it.

revelator commented 6 years ago

Well like you im in the unfortunate situation that i cannot maintain any more code :/ especially after my operation, since i simply cannot stand or sit at a computer for as long as i used to. But ill see what i can do, might be slow moving though.