Basically any GUI-ish application linking against our Qt (Cocoa backend) is broken. It crashes right on invocation. That should happen on x86-macos darwin9 upward and x64-macos. Reproducible: Always Steps to Reproduce: 1. Save the sample file 2. Run qmake -project && qmake && make 3. Invoke the resulting binary. Actual Results: ./s 2010-07-15 14:04:46.210 s[18689:903] *** __NSAutoreleaseNoPool(): Object 0x101d3e0d0 of class NSCFString autoreleased with no pool in place - just leaking 2010-07-15 14:04:46.212 s[18689:903] +[NSNotificationCenter sharedApplication]: unrecognized selector sent to class 0x7fff70e641a8 2010-07-15 14:04:46.213 s[18689:903] *** __NSAutoreleaseNoPool(): Object 0x103207510 of class NSCFString autoreleased with no pool in place - just leaking 2010-07-15 14:04:46.214 s[18689:903] *** __NSAutoreleaseNoPool(): Object 0x1032074e0 of class NSException autoreleased with no pool in place - just leaking 2010-07-15 14:04:46.214 s[18689:903] *** __NSAutoreleaseNoPool(): Object 0x101d3e2d0 of class _NSCallStackArray autoreleased with no pool in place - just leaking 2010-07-15 14:04:46.215 s[18689:903] *** __NSAutoreleaseNoPool(): Object 0x103207dd0 of class _NSCallStackArray autoreleased with no pool in place - just leaking 2010-07-15 14:04:46.215 s[18689:903] *** __NSAutoreleaseNoPool(): Object 0x103208010 of class NSCFString autoreleased with no pool in place - just leaking 2010-07-15 14:04:46.390 s[18689:903] *** __NSAutoreleaseNoPool(): Object 0x10205b400 of class NSCFString autoreleased with no pool in place - just leaking 2010-07-15 14:04:46.392 s[18689:903] *** __NSAutoreleaseNoPool(): Object 0x101d41950 of class NSConcreteMutableData autoreleased with no pool in place - just leaking 2010-07-15 14:04:46.393 s[18689:903] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[NSNotificationCenter sharedApplication]: unrecognized selector sent to class 0x7fff70e641a8' *** Call stack at first throw: ( 0 CoreFoundation 0x00007fff81e10cc4 __exceptionPreprocess + 180 1 libobjc.A.dylib 0x00007fff833e50f3 objc_exception_throw + 45 2 CoreFoundation 0x00007fff81e6a1d0 __CFFullMethodName + 0 3 CoreFoundation 0x00007fff81de2cdf ___forwarding___ + 751 4 CoreFoundation 0x00007fff81ddee28 _CF_forwarding_prep_0 + 232 5 QtGui 0x0000000100018f82 _Z7qt_initP19QApplicationPrivatei + 2761 6 QtGui 0x00000001000a91ba _ZN19QApplicationPrivate9constructEv + 60 7 QtGui 0x00000001000a94f8 _ZN12QApplicationC1ERiPPcbi + 132 8 s 0x0000000100002dbb main + 44 9 s 0x0000000100002c70 start + 52 ) terminate called after throwing an instance of 'NSException' Abort trap Expected Results: A small window with the text "Hello World!" in it. I've dug a bit around and found out the following: For my two targets qt4_install (prefix gcc-apple/binutils-apple, gcc version 4.2.1 (Gentoo 4.2.1_p5659, Apple Inc. build 5659)/@(#)PROGRAM:ld PROJECT:ld64-97.2 (Gentoo binutils-apple-3.2.2)) and qt4_hostcc_install (host/xcode gcc-apple/binutils-apple, gcc version 4.2.1 (Apple Inc. build 5664)/@(#)PROGRAM:ld PROJECT:ld64-97.14) I did a manual install with: ./configure -cocoa -framework -prefix $HOME/Temp/$name/ -no-webkit -no-script -no-svg -no-phonon -no-phonon-backend -no-audio-backend -no-multimedia -no-xmlpatterns -no-qt3support -release -fast Results are: qt4_install: Fails with the above error. qt4_hostcc_install: Nicely works. Thus I assume our gcc-apple and/or binutils-apple is barfed. Interestingly it used to work some time ago.
Created attachment 238881 [details] Test file to trigger the problem.
Additional note: The compiler/ld does only seem to matter for the compilation of Qt itself. That is compiling Qt with host's gcc/ld and compiling the application itself with prefix gcc/ld still makes it still work. I have the bad feeling that it's due to our lack of exception set up within in our ld.
Ok downgrading to sys-devel/gcc-apple-4.2.1_p5647 didn't help, so I additionally downgraded to sys-devel/binutils-apple-3.2-r1 (the one from my overlay) which seems to have worked. So maybe it's 'just' an ld issue. Did you do some serious modification to ld, Fabian?
yeah, your patches :)
(In reply to comment #4) > yeah, your patches :) > Umm, well then they aren't suited for the 97er series of ld or that specific version used in binutils-apple 3.2.2 has an Apple-side bug. Because I'm back on newest our gcc-apple and my binutils-apple 3.2-r1 and qt works. So it's definitely a linker problem, but I'm too lazy to find the real problem with that 3.2.2 one, now. Works nicely for my x64-macos box sys-devel/binutils-apple-3.2-r1 9the one from my overlay) sys-devel/gcc-apple-4.2.1_p5659 x11-libs/qt-core-4.6.3 x11-libs/qt-dbus-4.6.3 x11-libs/qt-gui-4.6.3 x11-libs/qt-qt3support-4.6.3 x11-libs/qt-script-4.6.3 x11-libs/qt-sql-4.6.3-r2
Urks, got another problem with your binutils-apple-3.2.2: [ticktock][~] >> mplayer mf:///usr/share/httpd/icons/world1.png MPlayer SVN-r30554-4.2.1 (C) 2000-2010 MPlayer Team Playing mf:///usr/share/httpd/icons/world1.png. MF file format detected. [mf] search expr: /usr/share/httpd/icons/world1.png* [mf] number of files: 1 (8) [demux_mf] file type was not set! trying 'type=png'... VIDEO: [MPNG] 0x0 24bpp 25.000 fps 0.0 kbps ( 0.0 kbyte/s) 2010-07-22 23:35:16.442 mplayer[67005:903] *** __NSAutoreleaseNoPool(): Object 0x101a16bc0 of class NSCFString autoreleased with no pool in place - just leaking 2010-07-22 23:35:16.444 mplayer[67005:903] +[NSScreen sharedApplication]: unrecognized selector sent to class 0x7fff70527aa0 2010-07-22 23:35:16.445 mplayer[67005:903] *** __NSAutoreleaseNoPool(): Object 0x101c0f050 of class NSCFString autoreleased with no pool in place - just leaking 2010-07-22 23:35:16.445 mplayer[67005:903] *** __NSAutoreleaseNoPool(): Object 0x101c03370 of class NSException autoreleased with no pool in place - just leaking 2010-07-22 23:35:16.446 mplayer[67005:903] *** __NSAutoreleaseNoPool(): Object 0x101c0f300 of class _NSCallStackArray autoreleased with no pool in place - just leaking 2010-07-22 23:35:16.447 mplayer[67005:903] *** __NSAutoreleaseNoPool(): Object 0x101c0f3b0 of class _NSCallStackArray autoreleased with no pool in place - just leaking 2010-07-22 23:35:16.447 mplayer[67005:903] An uncaught exception was raised 2010-07-22 23:35:16.448 mplayer[67005:903] +[NSScreen sharedApplication]: unrecognized selector sent to class 0x7fff70527aa0 2010-07-22 23:35:16.448 mplayer[67005:903] *** __NSAutoreleaseNoPool(): Object 0x101c0f550 of class NSCFString autoreleased with no pool in place - just leaking 2010-07-22 23:35:16.449 mplayer[67005:903] *** __NSAutoreleaseNoPool(): Object 0x101c0fe30 of class NSCFString autoreleased with no pool in place - just leaking 2010-07-22 23:35:16.450 mplayer[67005:903] *** __NSAutoreleaseNoPool(): Object 0x101c0f7f0 of class NSConcreteMutableData autoreleased with no pool in place - just leaking 2010-07-22 23:35:16.450 mplayer[67005:903] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[NSScreen sharedApplication]: unrecognized selector sent to class 0x7fff70527aa0' *** Call stack at first throw: ( 0 CoreFoundation 0x00007fff81e10cc4 __exceptionPreprocess + 180 1 libobjc.A.dylib 0x00007fff833e50f3 objc_exception_throw + 45 2 CoreFoundation 0x00007fff81e6a1d0 __CFFullMethodName + 0 3 CoreFoundation 0x00007fff81de2cdf ___forwarding___ + 751 4 CoreFoundation 0x00007fff81ddee28 _CF_forwarding_prep_0 + 232 5 mplayer 0x000000010001f21d preinit + 205 ) terminate called after throwing an instance of 'NSException' MPlayer interrupted by signal 6 in module: preinit_libvo - MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible bug. I'd say it screws up the objc stuff badly. I don't actually know what happens in preinit() but I guess it's the same as for qt: [NSApplication sharedApplication]. Interestingly it seems to get mapped to [NSScreen sharedApplication] this time, which doesn't exist. For qt it was mapped to [NSNotificationCenter sharedApplication] which also doesn't exist. Once again recompiling mplayer with the binutils-apple from my overlay fixes things. Looks like i need to verify things for 3.2.2 :/
Wait, your overlay? So you have a different version of the same 3.2.2 around? Or just an older one. This bug is seriously bad, so should we mask 3.2.2?
Wait for this bug getting fixed It also crash qemu, while try to make it work on OSX I guess it will crash any Cocoa based program $ qemu-system-x86_64 2010-07-30 10:25:23.039 qemu-system-x86_64[527:903] *** __NSAutoreleaseNoPool(): Object 0x100a16700 of class NSCFString autoreleased with no pool in place - just leaking 2010-07-30 10:25:23.051 qemu-system-x86_64[527:903] +[NSGraphicsContext sharedApplication]: unrecognized selector sent to class 0x7fff70ac6030 2010-07-30 10:25:23.051 qemu-system-x86_64[527:903] *** __NSAutoreleaseNoPool(): Object 0x100a1a180 of class NSCFString autoreleased with no pool in place - just leaking 2010-07-30 10:25:23.052 qemu-system-x86_64[527:903] *** __NSAutoreleaseNoPool(): Object 0x100a1a2a0 of class NSException autoreleased with no pool in place - just leaking 2010-07-30 10:25:23.053 qemu-system-x86_64[527:903] *** __NSAutoreleaseNoPool(): Object 0x100a1aa10 of class _NSCallStackArray autoreleased with no pool in place - just leaking 2010-07-30 10:25:23.053 qemu-system-x86_64[527:903] *** __NSAutoreleaseNoPool(): Object 0x100a1aa70 of class _NSCallStackArray autoreleased with no pool in place - just leaking 2010-07-30 10:25:23.067 qemu-system-x86_64[527:903] *** __NSAutoreleaseNoPool(): Object 0x100a1ad10 of class NSCFString autoreleased with no pool in place - just leaking 2010-07-30 10:25:23.160 qemu-system-x86_64[527:903] *** __NSAutoreleaseNoPool(): Object 0x100a1b830 of class NSCFString autoreleased with no pool in place - just leaking 2010-07-30 10:25:23.161 qemu-system-x86_64[527:903] *** __NSAutoreleaseNoPool(): Object 0x100a1ae00 of class NSConcreteMutableData autoreleased with no pool in place - just leaking 2010-07-30 10:25:23.162 qemu-system-x86_64[527:903] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[NSGraphicsContext sharedApplication]: unrecognized selector sent to class 0x7fff70ac6030' *** Call stack at first throw: ( 0 CoreFoundation 0x00007fff87613cc4 __exceptionPreprocess + 180 1 libobjc.A.dylib 0x00007fff81dde0f3 objc_exception_throw + 45 2 CoreFoundation 0x00007fff8766d1d0 __CFFullMethodName + 0 3 CoreFoundation 0x00007fff875e5cdf ___forwarding___ + 751 4 CoreFoundation 0x00007fff875e1e28 _CF_forwarding_prep_0 + 232 5 qemu-system-x86_64 0x00000001000ad4dc main + 107 6 qemu-system-x86_64 0x0000000100001e40 start + 52 ) terminate called after throwing an instance of 'NSException' Abort trap
(In reply to comment #7) > Wait, your overlay? So you have a different version of the same 3.2.2 around? > Or just an older one. This bug is seriously bad, so should we mask 3.2.2? > No I didn't have another version of 3.2.2 around. Anyway, "<binutils-apple-3.2.2" from the prefix tree works for me. So i guess x64-macos doesn't play particularly well with that ld64 version. So for now you'll *have to* downgrade binutils-apple at least on x64-macos on 10.6. Reilune can you confirm that emerge -1 "<binutils-apple-3.2.2" and then recompiling qemu makes it run again?
Oh wonder, oh wonder, sources for XCode 3.2.3 tooling is up: http://opensource.apple.com/release/developer-tools-323/ Go, Fabian ;)
> Reilune can you > confirm that emerge -1 "<binutils-apple-3.2.2" and then recompiling qemu makes > it run again? > downgrade to binutils-apple-3.2-r1, it works with binutils from OSX, it also works
Hmm @(#)PROGRAM:ld PROJECT:ld64-97.14 (Gentoo binutils-apple-3.2.3) still shows the problem :/ Fabian, if you haven't already seen the commit mails, you can grab the current version from my overlay (still needs patch tarball creation).
It's nasty... gtk also is broken... Once more on a call to [NSApplication sharedApplication] >> gtk-demo [...] 2010-08-05 22:54:43.744 gtk-demo[11437:903] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[NSEvent sharedApplication]: unrecognized selector sent to class 0x7fff70523180' *** Call stack at first throw: ( 0 CoreFoundation 0x00007fff81e10cc4 __exceptionPreprocess + 180 1 libobjc.A.dylib 0x00007fff833e50f3 objc_exception_throw + 45 2 CoreFoundation 0x00007fff81e6a1d0 __CFFullMethodName + 0 3 CoreFoundation 0x00007fff81de2cdf ___forwarding___ + 751 4 CoreFoundation 0x00007fff81ddee28 _CF_forwarding_prep_0 + 232 5 libgdk-quartz-2.0.0.dylib 0x0000000100085cf3 gdk_display_open + 67 6 libgdk-quartz-2.0.0.dylib 0x000000010005842d gdk_display_open_default_libgtk_only + 77 7 libgtk-quartz-2.0.0.dylib 0x00000001001d2af4 gtk_init_check + 20 8 libgtk-quartz-2.0.0.dylib 0x00000001001d2b09 gtk_init + 9 9 gtk-demo 0x00000001000136dd main + 77 10 gtk-demo 0x0000000100001094 start + 52 11 ??? 0x0000000000000001 0x0 + 1 ) terminate called after throwing an instance of 'NSException' Abort trap Interestingly it does not link against Cocoa.framework. So probably CoreFoundation.framework is the culprit then.
The port of the unwind patch from 95.x to 97.y grobian did, had some misplaced #endif's, resulting in missing essential Obj-C related parts. Should've looked there earlier though. Anyway, fixed patch can be found in my overlay. Mplayer and gtk work for me with @(#)PROGRAM:ld PROJECT:ld64-97.14 (Gentoo binutils-apple-3.2.3) now.
you can't possibly know how grateful I am for your digging and patchwork!
is this fixed in 3.2.3?
(In reply to comment #16) > is this fixed in 3.2.3? > Well, Qt, gtk+, pango and mplayer work for me with the fixed patch (tested with my 3.2.3, but probably also back-portable to 3.2.2).
I don't have SL, so I need somebody to test with the 3.2.3 from the prefix-tree, to ensure I didn't screw a patch up again...
(In reply to comment #18) > I don't have SL, so I need somebody to test with the 3.2.3 from the > prefix-tree, to ensure I didn't screw a patch up again... > Whoops, I did look into the prefix tree's timeline and assumed that version not being committed back then, though sys-devel/binutils-apple is in gx86's tree *cough* Anyway, just merged that version: [ebuild R ] sys-devel/binutils-apple-3.2.3 USE="-test" 0 kB [0=>1] [0] /Users/heiko/Gentoo/usr/portage and tried mplayer, which is working. So I guess the rest will also do its intended job on x64-macos on SL.
cool, thanks, fix0rzed in 3.2.3 then, makes 3.2.2 eligable for nuking