Re: preview: new macports ports
That sucks :-( Thanks for trying... The reason macports didn't uninstall the old versions of the ports may have been that I wasn't setting the version numbers on the ports properly. I fixed that, and also locked the SVN version that the ports check out for now, just so they're using a known-working version. On my OS 10.6.8 system I updated Xcode to 3.2.6, wiped Macports, and tried a fresh install of gorm, and was successful. Could you try running "otool -L" on a few binaries to see if anything is getting linked incorrectly? Here are the results I get: $ otool -L /opt/local/lib/libobjc-gnu.so.4.6.0 /opt/local/lib/libobjc-gnu.so.4.6.0: /opt/local/lib/libobjc-gnu.so.4.6.0 (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11) $ otool -L /opt/local/GNUstep/Local/Library/Libraries/libgnustep-base.1.23.dylib /opt/local/GNUstep/Local/Library/Libraries/libgnustep-base.1.23.dylib: /opt/local/GNUstep/Local/Library/Libraries/./libgnustep-base.1.23.dylib (compatibility version 0.0.0, current version 1.23.1) /opt/local/lib/libobjc-gnu.so.4.6.0 (compatibility version 0.0.0, current version 0.0.0) /opt/local/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.26.0) /opt/local/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.8.0) /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11) /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0) /opt/local/lib/libffi.5.dylib (compatibility version 6.0.0, current version 6.10.0) /opt/local/lib/libicui18n.48.dylib (compatibility version 48.0.0, current version 48.1.0) /opt/local/lib/libicuuc.48.dylib (compatibility version 48.0.0, current version 48.1.0) /opt/local/lib/libicudata.48.dylib (compatibility version 48.0.0, current version 48.1.0) $ otool -L `port dir gnustep-gui-devel`/work/trunk/Tools/obj/make_services /Users/ewasylishen/gnustep-macports-fixes/gnustep/gnustep-gui-devel/work/trunk/Tools/obj/make_services: /opt/local/lib/libicui18n.48.dylib (compatibility version 48.0.0, current version 48.1.0) /opt/local/lib/libicuuc.48.dylib (compatibility version 48.0.0, current version 48.1.0) /opt/local/lib/libicudata.48.dylib (compatibility version 48.0.0, current version 48.1.0) /opt/local/lib/libpng14.14.dylib (compatibility version 23.0.0, current version 23.0.0) /opt/local/GNUstep/Local/Library/Libraries/./libgnustep-base.1.23.dylib (compatibility version 0.0.0, current version 1.23.1) /opt/local/lib/libobjc-gnu.so.4.6.0 (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11) -Eric On 2011-11-19, at 2:50 AM, Ivan Vučica wrote: > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
You were right. For some reason I expected such stuff would automagically be handled. After uninstalling all GNUstep packages, there was no /opt/local/GNUstep to be deleted. There is now a crash in make_services. See attachment. On Fri, Nov 18, 2011 at 21:38, Eric Wasylishen wrote: > Hmm.. it appears there is an old install of GNUstep in your > /opt/local/GNUstep, and the build process is picking up headers from there > causing the problem. > > (sarray.h is part of the apple runtime, I think, and the only place > sarray.h is mentioned in base is at: > macosx/GNUstepBase/preface.h:74: "#include " > which I think is an old/unused file provided only for documentation > purposes.) > > Try uninstalling gnustep-make, then just delete /opt/local/GNUstep. > > -Eric > > On 2011-11-18, at 1:20 PM, Ivan Vučica wrote: > > Hello, > > I'm having issues with gnustep-base-devel. This is on OS X 10.6 with Xcode > 3.2.6. > > The-Evil-MacBook:macports ivucica$ clang --version > clang version 2.9 (tags/RELEASE_29/final) > Target: x86_64-apple-darwin10 > Thread model: posix > The-Evil-MacBook:macports ivucica$ which clang > /opt/local/bin/clang > > Looks like clang warns about redefinition of __weak. Also, it appears > clang cannot locate . > > :info:build In file included from GSObjCRuntime.m:32: > :info:build In file included from .././common.h:30: > :info:build In file included from > /opt/local/GNUstep/Local/Library/Headers/Foundation/NSZone.h:57: > :info:build In file included from > /opt/local/GNUstep/Local/Library/Headers/Foundation/NSObjCRuntime.h:32: > :info:build > /opt/local/GNUstep/Local/Library/Headers/GNUstepBase/preface.h:78:11: fatal > error: 'objc/sarray.h' file not found > :info:build #include > :info:build ^ > > I have also attached the log file. > > On Fri, Nov 18, 2011 at 20:18, Ivan Vučica wrote: > >> Zcode? Wow! *flattered* >> >> I really need to get back to working on it. >> >> I'm trying out the updated packages right now. >> >> On Thu, Nov 17, 2011 at 21:54, Eric Wasylishen wrote: >> >>> Hi, >>> Some updates on my macports ( >>> https://github.com/ericwa/gnustep-macports-fixes): I've switched them >>> to use clang and libobjc2, and have done some tidying. They are now working >>> on both of my systems: >>> Mac OS 10.6.8 / Xcode 3.2.5 (x86_64) >>> Mac OS 10.7.2 / Xcode 4.2 (x86_64) >>> >>> On 10.7, the system-provided clang is used; on 10.6 I install the clang >>> port from macports (currently version 2.9. I couldn't get the >>> system-provided clang, Apple version 1.6, to work.) >>> >>> Apps I've tested include GSTest, Gorm, and Zcode. Blocks and native ObjC >>> exceptions seem to be working on both systems. >>> >>> -Eric >>> >>> On 2011-11-09, at 11:39 AM, Eric Wasylishen wrote: >>> >>> This is great! Thanks for your effort. Btw. are those ports going to be >>> at the macports repository? >>> >>> >>> I hope they will be accepted! >>> >>> There are several things I would like to do before submitting them to >>> macports: >>> >>> - more testing >>> - hopefully get them working on OS 10.7 (they probably would work if the >>> gcc46 port wasn't broken :-) >>> - the old ports contained some hacks for installing man >>> pages/documentation... need to check if these are still needed >>> - maybe investigate getting them to compile with clang >>> - submit some of my patches to gnustep trunk >>> - once the next release of GNUstep comes out, get ports working with >>> that release (currently my ports require trunk) >>> >>> Cheers, >>> >>> Eric >>> >>> >>> >>> ___ >>> Gnustep-dev mailing list >>> Gnustep-dev@gnu.org >>> https://lists.gnu.org/mailman/listinfo/gnustep-dev >>> >>> >> >> >> -- >> Ivan Vučica - i...@vucica.net >> >> >> > > > -- > Ivan Vučica - i...@vucica.net > > > > > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev > > -- Ivan Vučica - i...@vucica.net main.log Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
On 18 Nov 2011, at 20:38, Eric Wasylishen wrote: > sarray.h is part of the apple runtime, I think Nope, it's part of the GCC runtime. It shouldn't be a public API, but it was for some reason and GNUstep included it for no reason. David -- Sent from my Difference Engine ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
Hmm.. it appears there is an old install of GNUstep in your /opt/local/GNUstep, and the build process is picking up headers from there causing the problem. (sarray.h is part of the apple runtime, I think, and the only place sarray.h is mentioned in base is at: macosx/GNUstepBase/preface.h:74: "#include " which I think is an old/unused file provided only for documentation purposes.) Try uninstalling gnustep-make, then just delete /opt/local/GNUstep. -Eric On 2011-11-18, at 1:20 PM, Ivan Vučica wrote: > Hello, > > I'm having issues with gnustep-base-devel. This is on OS X 10.6 with Xcode > 3.2.6. > > The-Evil-MacBook:macports ivucica$ clang --version > clang version 2.9 (tags/RELEASE_29/final) > Target: x86_64-apple-darwin10 > Thread model: posix > The-Evil-MacBook:macports ivucica$ which clang > /opt/local/bin/clang > > Looks like clang warns about redefinition of __weak. Also, it appears clang > cannot locate . > > :info:build In file included from GSObjCRuntime.m:32: > :info:build In file included from .././common.h:30: > :info:build In file included from > /opt/local/GNUstep/Local/Library/Headers/Foundation/NSZone.h:57: > :info:build In file included from > /opt/local/GNUstep/Local/Library/Headers/Foundation/NSObjCRuntime.h:32: > :info:build > /opt/local/GNUstep/Local/Library/Headers/GNUstepBase/preface.h:78:11: fatal > error: 'objc/sarray.h' file not found > :info:build #include > :info:build ^ > > I have also attached the log file. > > On Fri, Nov 18, 2011 at 20:18, Ivan Vučica wrote: > Zcode? Wow! *flattered* > > I really need to get back to working on it. > > I'm trying out the updated packages right now. > > On Thu, Nov 17, 2011 at 21:54, Eric Wasylishen wrote: > Hi, > Some updates on my macports > (https://github.com/ericwa/gnustep-macports-fixes): I've switched them to use > clang and libobjc2, and have done some tidying. They are now working on both > of my systems: > Mac OS 10.6.8 / Xcode 3.2.5 (x86_64) > Mac OS 10.7.2 / Xcode 4.2 (x86_64) > > On 10.7, the system-provided clang is used; on 10.6 I install the clang port > from macports (currently version 2.9. I couldn't get the system-provided > clang, Apple version 1.6, to work.) > > Apps I've tested include GSTest, Gorm, and Zcode. Blocks and native ObjC > exceptions seem to be working on both systems. > > -Eric > > On 2011-11-09, at 11:39 AM, Eric Wasylishen wrote: > >>> This is great! Thanks for your effort. Btw. are those ports going to be at >>> the macports repository? >> >> I hope they will be accepted! >> >> There are several things I would like to do before submitting them to >> macports: >> >> - more testing >> - hopefully get them working on OS 10.7 (they probably would work if the >> gcc46 port wasn't broken :-) >> - the old ports contained some hacks for installing man >> pages/documentation... need to check if these are still needed >> - maybe investigate getting them to compile with clang >> - submit some of my patches to gnustep trunk >> - once the next release of GNUstep comes out, get ports working with that >> release (currently my ports require trunk) >> >> Cheers, >> >> Eric > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev > > > > > -- > Ivan Vučica - i...@vucica.net > > > > > > -- > Ivan Vučica - i...@vucica.net > > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
Zcode? Wow! *flattered* I really need to get back to working on it. I'm trying out the updated packages right now. On Thu, Nov 17, 2011 at 21:54, Eric Wasylishen wrote: > Hi, > Some updates on my macports ( > https://github.com/ericwa/gnustep-macports-fixes): I've switched them to > use clang and libobjc2, and have done some tidying. They are now working on > both of my systems: > Mac OS 10.6.8 / Xcode 3.2.5 (x86_64) > Mac OS 10.7.2 / Xcode 4.2 (x86_64) > > On 10.7, the system-provided clang is used; on 10.6 I install the clang > port from macports (currently version 2.9. I couldn't get the > system-provided clang, Apple version 1.6, to work.) > > Apps I've tested include GSTest, Gorm, and Zcode. Blocks and native ObjC > exceptions seem to be working on both systems. > > -Eric > > On 2011-11-09, at 11:39 AM, Eric Wasylishen wrote: > > This is great! Thanks for your effort. Btw. are those ports going to be at > the macports repository? > > > I hope they will be accepted! > > There are several things I would like to do before submitting them to > macports: > > - more testing > - hopefully get them working on OS 10.7 (they probably would work if the > gcc46 port wasn't broken :-) > - the old ports contained some hacks for installing man > pages/documentation... need to check if these are still needed > - maybe investigate getting them to compile with clang > - submit some of my patches to gnustep trunk > - once the next release of GNUstep comes out, get ports working with that > release (currently my ports require trunk) > > Cheers, > > Eric > > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev > > -- Ivan Vučica - i...@vucica.net ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
On 17 Nov 2011, at 20:54, Eric Wasylishen wrote: > On 10.7, the system-provided clang is used; on 10.6 I install the clang port > from macports (currently version 2.9. I couldn't get the system-provided > clang, Apple version 1.6, to work.) That's probably expected. The clang in XCode 3.x was branched just before I made some fixes. Good to hear that the one in 4.2 works fine - that's only a couple of months old, so I expect it to, but it's always nice to see it tested... > Apps I've tested include GSTest, Gorm, and Zcode. Blocks and native ObjC > exceptions seem to be working on both systems. Very shiny! David -- Sent from my STANTEC-ZEBRA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
Hi, Some updates on my macports (https://github.com/ericwa/gnustep-macports-fixes): I've switched them to use clang and libobjc2, and have done some tidying. They are now working on both of my systems: Mac OS 10.6.8 / Xcode 3.2.5 (x86_64) Mac OS 10.7.2 / Xcode 4.2 (x86_64) On 10.7, the system-provided clang is used; on 10.6 I install the clang port from macports (currently version 2.9. I couldn't get the system-provided clang, Apple version 1.6, to work.) Apps I've tested include GSTest, Gorm, and Zcode. Blocks and native ObjC exceptions seem to be working on both systems. -Eric On 2011-11-09, at 11:39 AM, Eric Wasylishen wrote: >> This is great! Thanks for your effort. Btw. are those ports going to be at >> the macports repository? > > I hope they will be accepted! > > There are several things I would like to do before submitting them to > macports: > > - more testing > - hopefully get them working on OS 10.7 (they probably would work if the > gcc46 port wasn't broken :-) > - the old ports contained some hacks for installing man > pages/documentation... need to check if these are still needed > - maybe investigate getting them to compile with clang > - submit some of my patches to gnustep trunk > - once the next release of GNUstep comes out, get ports working with that > release (currently my ports require trunk) > > Cheers, > > Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
On Wed, Nov 9, 2011 at 19:33, Eric Wasylishen wrote: >> I'm unable to build GNUstep due to no fault of your own: compiling gcc46 >> fails in the linking phase of libgcc_s.1.dylib. This is on Snow Leopard. >> Apparently gcc46 uses its own linker to link this library. > > Hm, too bad. :-( When I install gcc46 on 10.6, macports uses this precompiled > binary: > http://packages.macports.org/gcc46/gcc46-4.6.2_0.darwin_10.x86_64.tbz2 , but > maybe your system is not x86_64? My system is most definitely x86_64. Maybe, however, Macports are configured as targeting i386. Can you privately send me your macports.conf? -- Ivan Vučica - i...@vucica.net ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
> This is great! Thanks for your effort. Btw. are those ports going to be at > the macports repository? I hope they will be accepted! There are several things I would like to do before submitting them to macports: - more testing - hopefully get them working on OS 10.7 (they probably would work if the gcc46 port wasn't broken :-) - the old ports contained some hacks for installing man pages/documentation... need to check if these are still needed - maybe investigate getting them to compile with clang - submit some of my patches to gnustep trunk - once the next release of GNUstep comes out, get ports working with that release (currently my ports require trunk) Cheers, Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
On 2011-11-08, at 1:59 PM, Ivan Vučica wrote: > Hi Eric, > > I'm unable to build GNUstep due to no fault of your own: compiling gcc46 > fails in the linking phase of libgcc_s.1.dylib. This is on Snow Leopard. > Apparently gcc46 uses its own linker to link this library. > > For now, I am giving up. Can some older GCC be used if I am not interested in > objc2.0 niceties? Hm, too bad. :-( When I install gcc46 on 10.6, macports uses this precompiled binary: http://packages.macports.org/gcc46/gcc46-4.6.2_0.darwin_10.x86_64.tbz2 , but maybe your system is not x86_64? I tried gcc44 and it doesn't work, unfortunately. Something wrong with detecting native exceptions. Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
Hi Eric, I'm unable to build GNUstep due to no fault of your own: compiling gcc46 fails in the linking phase of libgcc_s.1.dylib. This is on Snow Leopard. Apparently gcc46 uses its own linker to link this library. For now, I am giving up. Can some older GCC be used if I am not interested in objc2.0 niceties? On Tue, Nov 8, 2011 at 20:04, Eric Wasylishen wrote: > Ok, great! > > Here are a few more notes: > > - It installs using the GNUstep filesystem layout in /opt/local/GNUstep. > Using the fhs layout with macports will not work, because gnustep-make adds > the gnustep library path to DYLD_LIBRARY_PATH, which is /opt/local/lib with > the fhs layout, and if you add /opt/local/lib to DYLD_LIBRARY_PATH it will > mess up macports (basically, tools which link to apple versions of > libraries will pick up the macports versions in /opt/local/lib and break.) > > - Many of the application ports work now (e.g., gorm, systempreferences). > > - gnustep-back is currently set to xlib. When I use cairo, opening an > open/save panel crashes X11.app. Also tried the latest XQuartz: same > problem. > > - For anyone with OS X 10.7, my ports won't work until this bug is fixed: > https://trac.macports.org/ticket/31171 (building gcc46 on osx lion > fails). :-( > > - One improvement that could be made in the future is to use the system > compiler rather than the macports gcc46. For this we would need a portfile > which builds one of GNUstep's libobjc's, and make sure that the apple > compiler doesn't try to include headers for apple's libobjc. > > Regards > Eric > > On 2011-11-07, at 10:52 AM, Ivan Vučica wrote: > > Hi Eric, > > I've cloned the repo, and will be trying it out soon on my Snow Leopard > machine. If I forget to keep you posted, please poke me. > > On Mon, Oct 31, 2011 at 19:53, Eric Wasylishen wrote: > >> Hi, >> >> I started a new set of macports ports. If you want to try it you can >> check out a copy of the git repository here: >> https://github.com/ericwa/gnustep-macports-fixes and then set up that >> directory as a local portfile repository (see >> http://guide.macports.org/#development.local-repositories). >> > > -- > Ivan Vučica - i...@vucica.net > > > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev > > -- Ivan Vučica - i...@vucica.net ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
Am 08.11.2011 um 20:04 schrieb Eric Wasylishen: > Ok, great! > > Here are a few more notes: > > - It installs using the GNUstep filesystem layout in /opt/local/GNUstep. > Using the fhs layout with macports will not work, because gnustep-make adds > the gnustep library path to DYLD_LIBRARY_PATH, which is /opt/local/lib with > the fhs layout, and if you add /opt/local/lib to DYLD_LIBRARY_PATH it will > mess up macports (basically, tools which link to apple versions of libraries > will pick up the macports versions in /opt/local/lib and break.) > > - Many of the application ports work now (e.g., gorm, systempreferences). > > - gnustep-back is currently set to xlib. When I use cairo, opening an > open/save panel crashes X11.app. Also tried the latest XQuartz: same problem. > > - For anyone with OS X 10.7, my ports won't work until this bug is fixed: > https://trac.macports.org/ticket/31171 (building gcc46 on osx lion fails). :-( > > - One improvement that could be made in the future is to use the system > compiler rather than the macports gcc46. For this we would need a portfile > which builds one of GNUstep's libobjc's, and make sure that the apple > compiler doesn't try to include headers for apple's libobjc. > > Regards > Eric This is great! Thanks for your effort. Btw. are those ports going to be at the macports repository? Thanks, Lars___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
Ok, great! Here are a few more notes: - It installs using the GNUstep filesystem layout in /opt/local/GNUstep. Using the fhs layout with macports will not work, because gnustep-make adds the gnustep library path to DYLD_LIBRARY_PATH, which is /opt/local/lib with the fhs layout, and if you add /opt/local/lib to DYLD_LIBRARY_PATH it will mess up macports (basically, tools which link to apple versions of libraries will pick up the macports versions in /opt/local/lib and break.) - Many of the application ports work now (e.g., gorm, systempreferences). - gnustep-back is currently set to xlib. When I use cairo, opening an open/save panel crashes X11.app. Also tried the latest XQuartz: same problem. - For anyone with OS X 10.7, my ports won't work until this bug is fixed: https://trac.macports.org/ticket/31171 (building gcc46 on osx lion fails). :-( - One improvement that could be made in the future is to use the system compiler rather than the macports gcc46. For this we would need a portfile which builds one of GNUstep's libobjc's, and make sure that the apple compiler doesn't try to include headers for apple's libobjc. Regards Eric On 2011-11-07, at 10:52 AM, Ivan Vučica wrote: > Hi Eric, > > I've cloned the repo, and will be trying it out soon on my Snow Leopard > machine. If I forget to keep you posted, please poke me. > > On Mon, Oct 31, 2011 at 19:53, Eric Wasylishen wrote: > Hi, > > I started a new set of macports ports. If you want to try it you can check > out a copy of the git repository here: > https://github.com/ericwa/gnustep-macports-fixes and then set up that > directory as a local portfile repository (see > http://guide.macports.org/#development.local-repositories). > > -- > Ivan Vučica - i...@vucica.net > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
Hi Eric, I've cloned the repo, and will be trying it out soon on my Snow Leopard machine. If I forget to keep you posted, please poke me. On Mon, Oct 31, 2011 at 19:53, Eric Wasylishen wrote: > Hi, > > I started a new set of macports ports. If you want to try it you can check > out a copy of the git repository here: > https://github.com/ericwa/gnustep-macports-fixes and then set up that > directory as a local portfile repository (see > http://guide.macports.org/#development.local-repositories). > -- Ivan Vučica - i...@vucica.net ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
preview: new macports ports
Hi, I started a new set of macports ports. If you want to try it you can check out a copy of the git repository here: https://github.com/ericwa/gnustep-macports-fixes and then set up that directory as a local portfile repository (see http://guide.macports.org/#development.local-repositories). So far I've gotten gnustep-base-devel (which checks out the latest version of base from svn) to work quite well for me on OS X 10.6. The port uses macports-gcc-4.6 as a compiler. One nice thing - at least for 64-bit 10.6 - is macports has binary packages for most of the dependencies now, so you can try it out in a few minutes instead of a few hours. Here are the test results I got from base: 6361 Passed tests 16 Dashed hopes 7 Failed tests 1 Skipped set Failed test: NSGeometry1.m:102 ... In MacOSX geometry compat mode Failed test: create.m:26 ... +hostWithName: works for IPV6 addr Failed test: initialize.m:139 ... inherited +initialize is called automatically Failed test: performers.m:49 ... -performSelector:target:argument:order:modes: only sends the message once Failed test: performers.m:65 ... -performSelector:target:argument:order:modes: orders performers correctly Failed test: performers.m:89 ... -cancelPerformSelector:target:argument: works Failed test: thread.m:193 ... A loop with an input source will block Dashed hope: test02.m:284 ... foo->bar relative symlink not expanded by stringByResolvingSymlinksInPath Dashed hope: children.m:26 ... NSXML child handling working. Dashed hope: class_hierarchy.m:42 ... root class's metaclass is also its metaclass's metaclass Dashed hope: class_hierarchy.m:43 ... Root class is its metaclass's superclass Dashed hope: class_hierarchy.m:42 ... root class's metaclass is also its metaclass's metaclass Dashed hope: class_hierarchy.m:43 ... Root class is its metaclass's superclass Dashed hope: class_hierarchy.m:42 ... root class's metaclass is also its metaclass's metaclass Dashed hope: class_hierarchy.m:43 ... Root class is its metaclass's superclass Dashed hope: class_hierarchy.m:74 ... Metaclass's metaclass is root class's metaclass Dashed hope: class_hierarchy.m:74 ... Metaclass's metaclass is root class's metaclass Dashed hope: class_hierarchy.m:74 ... Metaclass's metaclass is root class's metaclass Dashed hope: class_hierarchy.m:74 ... Metaclass's metaclass is root class's metaclass Dashed hope: basic.m:53 ... working callStackSymbols ... if this has failed it is probably due to a lack of support for objective-c method names (local symbols) in the backtrace_symbols() function of your libc. If so, you might lobby your operating system provider for a fix. Dashed hope: general.m:125 ... Canonical identifier for 'AmericanEnglish is americanenglish Dashed hope: general.m:128 ... Canonical language identifier for 'AmericanEnglish is americanenglish Dashed hope: initialize.m:114 ... +initialize runs concurrently Skipped set: socket.m 146 ... NSStream SSL functions not supported --Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
