Re: Cross-compiling GNUstep?
Am 30.12.2013 07:34, schrieb Richard Frith-Macdonald: I have some little experience with CMake now ... it's a replacement for autoconf and automake (which are pretty horrible), unfortunately it's a cure which is worse than the disease. When it works, it's fine, but just like autoconf/automake, when it doesn't work or when you want to do something that hasn't been catered for, it's a nightmare and takes hours and hours to work out how things operate. Thanks for the opinion. My first impression of CMake actually aligns with this: while it has quite a number of interesting features, it's also close to be overengineered. I just see my shiny new Debian packages don't allow me to build -base without debian/rules. I'm not sure what that means, but it sounds like a Debain packaging issue orthogonal to any issues in autoconf. At the bottom line, packaging does just four things: 1. Run the projects' prefered configuration procedure (in case of GNUstep this is ./configure). 2. Run the projects' prefered build procedure (in case of GNUstep this is make). 3. Install into a OS installation as virgin as possible (just the dependencies installed), using the projects' installation procedure. 4. Tar up the files installed by 3. Accordingly, if this doesn't work, it's very likely it doesn't work when doing the same steps manually, either. What makes packaging complicated is their insistence on working in release cycles (there's room for improvement) and the fact you always install into a virgin system (which is a good thing). BUT, as said in that other email I was probably just confused by the way tests/checks are run. They build run when invoked from Tests/, but not when invoked from (e.g.) Tests/gui/NSCell. And the lack of visible messages isn't a bug, but a feature :-} Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.reprap-diy.com/ http://www.jump-ing.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
On 30 Dec 2013, at 07:23, Richard Frith-Macdonald richardfrithmacdon...@gmail.com wrote: In my experience CMake is far more of a burden because it doesn't have the years of documentation development that autoconf has, and (more importantly to me) because its a monolithic C program. You need to get the source and figure out what it's doing, and that's just easier to do with the configure script and macros in autoconf. This is simply not true. The vast majority of the logic of cmake is in the .cmake files. The 'monolithic C program' (which is written in C++) is just the interpreter. Large library projects typically distribute their own .cmake files containing specific rules for their build systems, but these compose with other rules. For example, LLVM ships a bunch of .cmake files, which libobjc2 uses when building the LLVM optimisation passes. Qt, KDE, and so on all ship custom .cmake files that simplify building apps for those platforms. I don't think I've ever looked at the source for CMake, though I use it for a number of projects - I've always found what I needed to do by either reading the documentation or searching their mailing list archives. My main attraction to CMake, however, is not CMake itself as much as Ninja, which dramatically improves life when doing a lot of incremental builds. LLVM has both CMake and autoconf+make build systems. After changing one file, the Ninja files that CMake generates can do an incremental build in less time than it takes for the GNU Make build system to determine that it has no work to do if you don't change any files. Oh, and when it needs to reconfigure, rerunning cmake takes about a fifth of the time that running ./configure takes, even though it's actually doing more work (configure just sets some flags for some hand-written Makefiles to use, cmake generates the build system). For OS X users, there's a nice CMake GUI that lets you generate XCode project files, which I imagine would be very attractive to users wanting to run GNUstep code on that platform. The generated XCode files aren't perfect, but they're a lot easier for OS X developers to use than GNUstep Make. Oh, and they already support building .app and .framework bundles on OS X, so it should be possible to reuse some of this code, which might even give us some existing OS X applications running on GNUstep for free... That said, I completely agree with Fred, that there's no point discussing a change of build system without at least a proof of concept demonstration that another one would work. I would, however, suggest that this would be much easier to do if we had some documentation describing things like the various filesystem / bundle layouts. David -- Sent from my Cray X1 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Android (Was: Cross-compiling GNUstep?)
Hi Ivan, I wonder if it makes sense to build shared libraries at all on Android. It's a single toggle in the libobjc build to get a static library, and as long as you make sure -fPIC is in the [OBJ]C[XX]FLAGS you can then link this to GNUstep base. Doing the same thing for the GNUstep libraries would probably also make sense. Since the 'shared' libraries on Android aren't really shared, it would be good longer-term to be able to do LTO on the entire app+GNUstep+whatever. The only slight irritation with this is the LGPL, which means that you then can't distribute via the app store, unless you also distribute your .o files along with the app (the runtime is MIT licensed, so doesn't have this problem), but for open source Android apps it would be fine. For everything else, we could build a single libgnustep.so that contained all of the libraries that GNUstep depends upon. David On 30 Dec 2013, at 00:51, Ivan Vučica i...@vucica.net wrote: Hi all, (David, please take a look below) I've sit down tonight and got gnustep-base to run under Android. The hardest part is having to manually load the dynamic libraries; apparently Android's android.app.NativeActivity is dumb enough to fail miserably when it has to (oh shock and horror) load a library that the .so containing native depends on. (For those who don't know, Android applications cannot be written purely in native code. Even NativeActivity class, introduced relatively late and used primarily for games, is code written in Java that loads a shared object library and calls native code at appropriate times.) Native code on Android in any non-console application is delivered as an .so. If it shows up on screen, it's not a standalone ELF executable. Simple as that. Hence the modus operandi is this: Application is always written in Java. Java code uses JNI to load an .so. Java code then calls C functions as appropriate. Native code may call back into Java. -- Where was I stuck? When it comes to usual GNU/Linux systems, libobjc2 is a good behaving citizen that specifies soname in the form of libobjc.so.4.6; when it comes to Android systems, libgnustep-base is a better behaving citizen that specifies so name in the form of libgnustep-base.so. On regular systems, end user may not notice, as both are shipped as libXYZ.so.A.B and symlinked into libXYZ.so. libobjc2 follows the recommendations, though, and libgnustep-base does not. Doesn't really matter on Android, as the requirements are completely opposite; if you put a binary in ...apkroot/lib/armeabi and it doesn't have the extension .so, it won't get shipped. Dynamic loader will choke when trying to load libgnustep-base.so which references to libobjc2 based on its soname; same for libAPPNAME.so. David: The hack that I found online, where I edit libgnustep-base.so and libAPPNAME.so to replace libobjc.so.4.6 with libobjc.so\0\0\0\0 is just that - a hack. Can you look into the best way to force CMake to pass -soname libobjc.so to the linker, but just on Android? I have a CMake toolchain file for Android, but I'm unsure how to specify that the version number should not be suffixed on Android. -- So, what does the .apk that I have do? Nothing much: NSString * hello = @hello; LOGI([hello UTF8String]); which is just enough to see the output in Android's logcat. -- Where is the updated script to build gnustep-base for Android, and where is the demo application? In private Bitbucket repositories. While I'm looking forward to approval to release relevant code from my employer, I'll stay cautious. When/if I get the approval, I'll push the updated code into publicly available repositories. Publicly available code: http://bitbucket.org/ivucica/gnustep-android http://bitbucket.org/ivucica/thegrandexperiment First repository contains non-up-to-date code to fetch Android SDK and NDK, create standalone toolchain, fetch gnustep-make, gnustep-base and libobjc2, patch gnustep-base appropriately, build and install libobjc2, gnustep-make and gnustep-base. Second repository demonstrates how to build an Android application without having to use the Android build system. Sadly, it has a lot of hardcoded paths, and Windows paths at that. Updated version still has a lot of hardcoded paths, but at least they're under Linux (and match the .../gnustep-android paths). -- What did I have to do? I'll describe the updates to gnustep-android repo, in case approval doesn't come or someone wants to upstream the changes. First, since the two patches that I had were not applying cleanly, I removed them. Maybe relevant fixes, relating to 'daylight' and 'dladdr branch in objc-load code' are upstream already. Second, -base's SSL subdirectory was being used even when --disable-openssl was passed. Worse, when its configure was called, it did not receive the same flags as the root
Re: Android (Was: Cross-compiling GNUstep?)
Hi David, On Mon Dec 30 2013 at 10:27:18 AM, David Chisnall thera...@sucs.org wrote: Hi Ivan, I wonder if it makes sense to build shared libraries at all on Android. It may not, but by now it's been dealt with :-) I definitely was wondering about the possibility of using static libraries. It's a single toggle in the libobjc build to get a static library, and as long as you make sure -fPIC is in the [OBJ]C[XX]FLAGS you can then link this to GNUstep base. Doing the same thing for the GNUstep libraries would probably also make sense. I'll look into this. Still, if one wants to build separate libobjc, could you look into forcing soname to be just libobjc.so, solely for the Android platform? If I understand the CMake way of thinking, that should be done in the toolchain specification file, right? Since the 'shared' libraries on Android aren't really shared, it would be good longer-term to be able to do LTO on the entire app+GNUstep+whatever. The only slight irritation with this is the LGPL, which means that you then can't distribute via the app store, unless you also distribute your .o files along with the app (the runtime is MIT licensed, so doesn't have this problem), but for open source Android apps it would be fine. For everything else, we could build a single libgnustep.so that contained all of the libraries that GNUstep depends upon. Even before I read the entire mail the first thought that came to me was the legal issues with LGPL. :-) And single libgnustep.so does sound like a good approach for any proprietary apps. We could support 3 scenarios: - fully statically linked with app (with a big label about advantages plus about legal requirements) - statically linked up to libgnustep.so - every library for itself ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Android (Was: Cross-compiling GNUstep?)
On 30 Dec 2013, at 10:58, Ivan Vučica ivuc...@gmail.com wrote: Still, if one wants to build separate libobjc, could you look into forcing soname to be just libobjc.so, solely for the Android platform? If I understand the CMake way of thinking, that should be done in the toolchain specification file, right? The version extension is set by the SOVERSION target property, which is used to define the extension. If you can give me a way of detecting that Android is the target, then it's easy to either not set this, or explicitly set the NO_SONAME target property to true (which has the same effect). Even before I read the entire mail the first thought that came to me was the legal issues with LGPL. :-) And single libgnustep.so does sound like a good approach for any proprietary apps. We could support 3 scenarios: - fully statically linked with app (with a big label about advantages plus about legal requirements) - statically linked up to libgnustep.so - every library for itself I'm not sure that there's any advantage in the last one, to be honest. With the statically linked libgnustep.so, we get the possibility of doing LTO (which should reduce binary sizes, which is probably a good thing for Android!) and of doing more of the relocations statically so that we will get faster startup times. David -- Sent from my Apple II ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
Am 30.12.2013 11:26, schrieb David Chisnall: That said, I completely agree with Fred, that there's no point discussing a change of build system without at least a proof of concept demonstration that another one would work. I would, however, suggest that this would be much easier to do if we had some documentation describing things like the various filesystem / bundle layouts. Filesystem layouts are here (and you have to support many of them): http://svn.gna.org/viewcvs/gnustep/tools/make/trunk/FilesystemLayouts/ Regarding bundle layouts, there's this: http://wiki.gnustep.org/index.php/User_FAQ#Why_not_use_framework_bundles.3F and of course this: https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/1123i-CH101-SW28 (Bundle Programming Guide) All of them mean you have to be very flexible about where to install files. Less about how to build the files. Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.reprap-diy.com/ http://www.jump-ing.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
I asked for it, I got it and now it doesn't help me :-( Thank you for the stack trace. But now I am completely clueless. Do you have an idea why the message NSWindow.m: No such file or directory. shows up? I would expect that you are running Gorm on the same machine that you did compile GNUstep. If this is the case gdb should be able to find the source file, as long as you did not strip that information from the library. But you wrote that you did not request any optimization. One last thing, could you please run ldd against your Gorm executable and report back the result? Just to make sure that the correct GNUstep library files get used. Looking at the code in NSWindow sendEvent: I see no way how self could ever become nil. Fred On 30.12.2013 00:32, Jamie Ramone wrote: OK, here it is: (gdb) file /SystemApps/Gorm.app/Gorm Reading symbols from /SystemApps/Gorm.app/Gorm...done. (gdb) r Starting program: /SystemApps/Gorm.app/Gorm [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. Program received signal SIGSEGV, Segmentation fault. -[NSWindow sendEvent:] (self=0x0, _cmd=optimized out, theEvent=0xe121e0) at NSWindow.m:4414 4414NSWindow.m: No such file or directory. (gdb) bt #0 -[NSWindow sendEvent:] (self=0x0, _cmd=optimized out, theEvent=0xe121e0) at NSWindow.m:4414 #1 0x771ef09c in -[GSDragView(Private) _handleDrag:slidePoint:] ( self=0xc55d00, _cmd=optimized out, theEvent=0x1061780, slidePoint=...) at GSDragView.m:720 #2 0x771ed20e in -[GSDragView dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc55d00, _cmd=optimized out, anImage=0x9dc150, screenLocation=..., initialOffset=..., event=0x11073a0, pboard=optimized out, sourceObject=0xf2e5f0, slideFlag=1 '\001') at GSDragView.m:290 #3 0x7045e344 in -[XGDragView dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc55d00, _cmd=optimized out, anImage=0x9dc150, screenLocation=..., initialOffset=..., event=0x11073a0, pboard=0x9d9470, sourceObject=0xf2e5f0, slideFlag=1 '\001') at XGDragView.m:228 #4 0x771bebda in -[NSWindow dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xb140b0, _cmd=optimized out, anImage=0x9dc150, baseLocation=..., initialOffset=..., event=0x11073a0, pboard=optimized out, sourceObject=optimized out, slideFlag=1 '\001') at NSWindow.m:4674 #5 0x771a8c08 in -[NSView dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xf2e5f0, _cmd=optimized out, anImage=0x9dc150, ---Type return to continue, or q return to quit--- viewLocation=..., initialOffset=..., event=0x11073a0, pboard=optimized out, sourceObject=optimized out, slideFlag=1 '\001') at NSView.m:3860 #6 0x77b2983c in -[GormObjectEditor mouseDown:] (self=0xf2e5f0, _cmd=optimized out, theEvent=0x11073a0) at GormObjectEditor.m:481 #7 0x771ca953 in -[NSWindow sendEvent:] (self=0xb140b0, _cmd=optimized out, theEvent=0x11073a0) at NSWindow.m:3896 #8 0x770343e3 in -[NSApplication run] (self=0x8c8450, _cmd=optimized out) at NSApplication.m:1562 #9 0x770130d5 in NSApplicationMain (argc=optimized out, argv=optimized out) at Functions.m:91 #10 0x75eab76d in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #11 0x00401965 in _start () (gdb) On Sun, Dec 29, 2013 at 6:50 PM, Fred Kiefer fredkie...@gmx.de wrote: Yes! That was what I was asking for. Thank you, Fred On 29.12.2013 22:28, Jamie Ramone wrote: I'm not sure how much more details you need. I stated that dragging a connection to any of the objects in the document window (i.e. the main project window) caused a segfault. I later discovered that dragging from these objects toward any other one, outside that window, worked OK. And it seems to be present in the current version of Gorm and updating the GNUstep libs didn't alleviate the problem, which says to me that it's Gorm-specific. Oh and the GDB backtrace is from the old code. Would it help to make another one with the new code? If so just let me know and I'll produce one. On Sun, Dec 29, 2013 at 6:20 PM, Fred Kiefer fredkie...@gmx.de wrote: On 29.12.2013 21:58, Gregory Casamento wrote: Between windows or between applications. I believe you’re hitting the same bug Fred may be hitting, I’m working on a potential fix now. You might be wrong here. German's bug, that I investigated, was Gorm specific. If you advice Jamie to drag between another application and GWorkspace it may never trigger the same bug. It might trigger a similar bug in GWorkspace if it has similar code to Gorm, but how likely is that? And I wasn't able to reproduce Jamie's bug with Gorm. But then he never gave enough details to be sure. As you may remember German's bug did not include a segmentation fault, which is the
Re: Serious GORM bug
No idea about the NSWindow.m not found. I am running it on the machine it was compiled for. I did delete the sources afterward, but doesn't the code info get included with -g? If necessary, I can unpack the sources where I did the build last time. Would that help in the bug hunt? Just let me know. Here's the ldd output: jamie@MyPC:~$ ldd /SystemApps/Gorm.app/Gorm linux-vdso.so.1 = (0x7fff0cfff000) libGormCore.so.1 = /SystemLibrary/Libraries/libGormCore.so.1 (0x7fd04788e000) libGorm.so.1 = /SystemLibrary/Libraries/libGorm.so.1 (0x7fd04767e000) libGormPrefs.so.1 = /SystemLibrary/Libraries/libGormPrefs.so.1 (0x7fd047465000) libgnustep-gui.so.0.24 = /SystemLibrary/Libraries/libgnustep-gui.so.0.24 (0x7fd046c46000) libgnustep-base.so.1.24 = /SystemLibrary/Libraries/libgnustep-base.so.1.24 (0x7fd04649b000) libobjc.so.3 = /usr/lib/x86_64-linux-gnu/libobjc.so.3 (0x7fd04625f000) libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fd046049000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fd045c89000) libGormObjCHeaderParser.so.1 = /SystemLibrary/Libraries/libGormObjCHeaderParser.so.1 (0x7fd045a7b000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fd04585e000) libicuuc.so.48 = /usr/lib/libicuuc.so.48 (0x7fd0454f4000) libpng12.so.0 = /lib/x86_64-linux-gnu/libpng12.so.0 (0x7fd0452cb000) libgif.so.4 = /usr/lib/x86_64-linux-gnu/libgif.so.4 (0x7fd0450c2000) libtiff.so.4 = /usr/lib/x86_64-linux-gnu/libtiff.so.4 (0x7fd044e5e000) libjpeg.so.8 = /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x7fd044c0d000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fd044911000) libgnutls.so.26 = /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x7fd044655000) libgcrypt.so.11 = /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x7fd0443d6000) libxslt.so.1 = /usr/lib/x86_64-linux-gnu/libxslt.so.1 (0x7fd04419a000) libxml2.so.2 = /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x7fd043e3e000) libffi.so.6 = /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x7fd043c35000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fd043a31000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7fd04381a000) libicui18n.so.48 = /usr/lib/libicui18n.so.48 (0x7fd043451000) /lib64/ld-linux-x86-64.so.2 (0x7fd047bf5000) libicudata.so.48 = /usr/lib/libicudata.so.48 (0x7fd0420e1000) libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fd041de) libtasn1.so.3 = /usr/lib/x86_64-linux-gnu/libtasn1.so.3 (0x7fd041bcf000) libp11-kit.so.0 = /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x7fd0419bc000) libgpg-error.so.0 = /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x7fd0417b8000) On Mon, Dec 30, 2013 at 1:55 PM, Fred Kiefer fredkie...@gmx.de wrote: I asked for it, I got it and now it doesn't help me :-( Thank you for the stack trace. But now I am completely clueless. Do you have an idea why the message NSWindow.m: No such file or directory. shows up? I would expect that you are running Gorm on the same machine that you did compile GNUstep. If this is the case gdb should be able to find the source file, as long as you did not strip that information from the library. But you wrote that you did not request any optimization. One last thing, could you please run ldd against your Gorm executable and report back the result? Just to make sure that the correct GNUstep library files get used. Looking at the code in NSWindow sendEvent: I see no way how self could ever become nil. Fred On 30.12.2013 00:32, Jamie Ramone wrote: OK, here it is: (gdb) file /SystemApps/Gorm.app/Gorm Reading symbols from /SystemApps/Gorm.app/Gorm...done. (gdb) r Starting program: /SystemApps/Gorm.app/Gorm [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. Program received signal SIGSEGV, Segmentation fault. -[NSWindow sendEvent:] (self=0x0, _cmd=optimized out, theEvent=0xe121e0) at NSWindow.m:4414 4414NSWindow.m: No such file or directory. (gdb) bt #0 -[NSWindow sendEvent:] (self=0x0, _cmd=optimized out, theEvent=0xe121e0) at NSWindow.m:4414 #1 0x771ef09c in -[GSDragView(Private) _handleDrag:slidePoint:] ( self=0xc55d00, _cmd=optimized out, theEvent=0x1061780, slidePoint=...) at GSDragView.m:720 #2 0x771ed20e in -[GSDragView dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc55d00, _cmd=optimized out, anImage=0x9dc150, screenLocation=..., initialOffset=..., event=0x11073a0, pboard=optimized out, sourceObject=0xf2e5f0, slideFlag=1 '\001') at GSDragView.m:290 #3 0x7045e344 in -[XGDragView dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc55d00, _cmd=optimized out, anImage=0x9dc150, screenLocation=..., initialOffset=...,
Re: Serious GORM bug
El lun, 30-12-2013 a las 15:30 -0200, Jamie Ramone escribió: No idea about the NSWindow.m not found. I am running it on the machine it was compiled for. I did delete the sources afterward, but doesn't the code info get included with -g? If necessary, I can unpack the sources where I did the build last time. Would that help in the bug hunt? Just let me know. Here's the ldd output: jamie@MyPC:~$ ldd /SystemApps/Gorm.app/Gorm linux-vdso.so.1 = (0x7fff0cfff000) linux-vdso.so is used only in recent kernels at 64 bits machines. So, could be a problem with this library? Searching on internet, seems there are people having problems with this. Germán. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
Hmm, interesting. What could be a good workaround? Can it safely be removed or downgraded? Keep in mind that I'm on Ubuntu 12.04. On Mon, Dec 30, 2013 at 3:27 PM, Germán Arias germanan...@gmx.es wrote: El lun, 30-12-2013 a las 15:30 -0200, Jamie Ramone escribió: No idea about the NSWindow.m not found. I am running it on the machine it was compiled for. I did delete the sources afterward, but doesn't the code info get included with -g? If necessary, I can unpack the sources where I did the build last time. Would that help in the bug hunt? Just let me know. Here's the ldd output: jamie@MyPC:~$ ldd /SystemApps/Gorm.app/Gorm linux-vdso.so.1 = (0x7fff0cfff000) linux-vdso.so is used only in recent kernels at 64 bits machines. So, could be a problem with this library? Searching on internet, seems there are people having problems with this. Germán. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Android (Was: Cross-compiling GNUstep?)
On 30 Dec 2013, at 16:32, Doug Warren doug.war...@gmail.com wrote: Now would also be a good time to mention imp_implementationWithBlock() requires filesystem access and assumes that you can call getEnv(TMP) to get the write directory. I think someone here reimplemented it as mmap/mprotect but I haven't had a chance to check on it yet. On Android, this can probably use anonymous shared memory regions, or if Android doesn't use W^X we can just use fallback code that maps the memory in the same place for read and execute permission. Given Android's typical attitude to security, option 2 would probably work. David -- This email complies with ISO 3103 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Update to webpage
On Dec 27, 2013, at 5:08 AM, Fred Kiefer fredkie...@gmx.de wrote: The main link for GNUstep installation on our wiki leads to this page: http://www.gnustep.org/resources/documentation/User/GNUstep/gnustep-howto_toc.html It is from 2008 and partly outdated. It also misses all the sub-sections of section 6, which would be the machine specific instructions. Most likely somebody manually changed the page http://www.gnustep.org/resources/documentation/User/GNUstep/gnustep-howto_6.html but forgot to update the index page as well. Could somebody please update the index as well? I think this document should be generated from a file in GNUstep make. Actually I’d like to move the HOWTO to the Wiki - it’s almost all there anyway and more up-to-date. Probably the simplest way to make GNUstep look more active is to have more of the content on the Wiki where more people can update it and make it look fresh. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
GNUstep.org website redesign proposal
Hi all, I guess everybody knows, and also agrees that the GNUstep website is looking fairly dated, and that finding contents in it, is somtetimes only possible with help of google. the last few days I spent on thinking about the website, what it may need, digging html5 and css3, and came up with the following design, that you can find here: https://www.l00-bugdead-prods.de/index7.html Note, not all pages and links are implemented. I did not wanted to waste too much time, in case, the majority of people doesn't like with what I've come up. Older revisions, that finally lead to the design I have now, can be seen here: https://www.l00-bugdead-prods.de/index3.html https://www.l00-bugdead-prods.de/index5.html https://www.l00-bugdead-prods.de/index6.html The major design goals of the page are: * have a half way modern look, but don't overdo * easy and logical menu structuring, it should be easy to find things following a logic Further Ideas and things I had considered while designing were: Intended main audience: * MAC Developers seeking to port their apps to other platforms * Developers from other platforms, seeking to base their projects, commercial or free, on GNUstep * Packagers, that want to package GNUstep for their favourite OS/Distribution Not intended main audience, but also welcomed: * End users of any kind * direct End users to the pages to GWorkspace or SystemPreferences, Example applications, and screenshots * otherwise, direct end users to GAP and maybe other external sites Why chose the main audience above? * GNUstep is a set of libraries, providing an API to be used by developers * libraries are accompanied by a set of development tools * GWorkspace and SystemPreferences are nice show cases for developers that want to get to know what they can get from GNUstep General design goals of the page: * Its generally intended to attract the main intended audience * have a modern look and feel, but keep the page simple * page should work with recent modern browsers * making use of modern HTML5 and CSS3 * page may look a bit odd with old browsers (this likely includes SWK ;) * but who is really using a browser that does not understand HTML5/CSS3, or at least a subset of it? Even Google doesn't support old browsers. * simple wording, short and clear sentences * simple page structure, simulating the MAC Desktop * main menu (the dock at the bottom on every page) * always all the time visible * horizontal menu on the top dependent on what's chosen from the dock at the bottom * the icon on the left shows which menu entry was chosen from the dock at the bottom Some more specific design decisions are based on: * design of the contents of the homepage: * do not overload with information or images, the page should load fast ;) * address the most interesting questions someone looking for GNUstep might have with links to the right subpages * generally inspired from www.gtk.org * Footer/Dock: * show some modern CSS tricks, hopefully giving the (right) impression of GNUstep being modern too * mostly white background * white looks clean * but if there are better suggestions, and a different background color can be agreed on, then it should be ;) * horizontal top menu is inspired by www.apple.com * make Mac developers feel at home * its simple, looking nice * no submenus, but having submenus there, if agreed on, can easily be added, see an older incarnation of the design: https://www.l00-bugdead-prods.de/index3.html * the icon on the left is the same as the one clicked at the bottom, in order to signal where the user currently is * grey color in the horizontal menu on the top, and other elements * GNUstep apps are grey, or maybe in the future that will (hopefully) change when another theme gets included in GUI, but the color is chosen in reference to the GUI apps and history to NeXT * but if there are other suggestions for coloring the menu and other elements, and it can be agreed on, then it should be ;) * text alignment is justified * differentiate external links: those are marked with icon * News box on front page: * shows news on, releases, hackathons, papers, etc. * shows there is live in the community * New pages: hackathons page and papers page: * show there is live in the community * show there is fun in the community * make use of SSIs, to ease updating, at least for the top menu, and the dock at the bottom, and for example the news box on the front page * The screenshot pages should show off more Themes to underline GNUsteps flexibility in the look 'n feel Design ideas inspired by: * Footer: MAC OS X dock * horizontal top menu: www.apple.com * main page: www.gtk.org * screenshot gallery: www.gtk.org Main Menu structure (the dock at the bottom) * About GNUstep * about the project, and all other advocacy related stuff * Software * information about what the
Re: GNUstep.org website redesign proposal
Hi Sebastian El mar, 31-12-2013 a las 02:09 +0100, Sebastian Reitenbach escribió: Hi all, I guess everybody knows, and also agrees that the GNUstep website is looking fairly dated, and that finding contents in it, is somtetimes only possible with help of google. the last few days I spent on thinking about the website, what it may need, digging html5 and css3, and came up with the following design, that you can find here: https://www.l00-bugdead-prods.de/index7.html News at main website, was about to suggest this, because in this way we can do a better use of wiki. Germán. Note, not all pages and links are implemented. I did not wanted to waste too much time, in case, the majority of people doesn't like with what I've come up. Older revisions, that finally lead to the design I have now, can be seen here: https://www.l00-bugdead-prods.de/index3.html https://www.l00-bugdead-prods.de/index5.html https://www.l00-bugdead-prods.de/index6.html The major design goals of the page are: * have a half way modern look, but don't overdo * easy and logical menu structuring, it should be easy to find things following a logic Further Ideas and things I had considered while designing were: Intended main audience: * MAC Developers seeking to port their apps to other platforms * Developers from other platforms, seeking to base their projects, commercial or free, on GNUstep * Packagers, that want to package GNUstep for their favourite OS/Distribution Not intended main audience, but also welcomed: * End users of any kind * direct End users to the pages to GWorkspace or SystemPreferences, Example applications, and screenshots * otherwise, direct end users to GAP and maybe other external sites Why chose the main audience above? * GNUstep is a set of libraries, providing an API to be used by developers * libraries are accompanied by a set of development tools * GWorkspace and SystemPreferences are nice show cases for developers that want to get to know what they can get from GNUstep General design goals of the page: * Its generally intended to attract the main intended audience * have a modern look and feel, but keep the page simple * page should work with recent modern browsers * making use of modern HTML5 and CSS3 * page may look a bit odd with old browsers (this likely includes SWK ;) * but who is really using a browser that does not understand HTML5/CSS3, or at least a subset of it? Even Google doesn't support old browsers. * simple wording, short and clear sentences * simple page structure, simulating the MAC Desktop * main menu (the dock at the bottom on every page) * always all the time visible * horizontal menu on the top dependent on what's chosen from the dock at the bottom * the icon on the left shows which menu entry was chosen from the dock at the bottom Some more specific design decisions are based on: * design of the contents of the homepage: * do not overload with information or images, the page should load fast ;) * address the most interesting questions someone looking for GNUstep might have with links to the right subpages * generally inspired from www.gtk.org * Footer/Dock: * show some modern CSS tricks, hopefully giving the (right) impression of GNUstep being modern too * mostly white background * white looks clean * but if there are better suggestions, and a different background color can be agreed on, then it should be ;) * horizontal top menu is inspired by www.apple.com * make Mac developers feel at home * its simple, looking nice * no submenus, but having submenus there, if agreed on, can easily be added, see an older incarnation of the design: https://www.l00-bugdead-prods.de/index3.html * the icon on the left is the same as the one clicked at the bottom, in order to signal where the user currently is * grey color in the horizontal menu on the top, and other elements * GNUstep apps are grey, or maybe in the future that will (hopefully) change when another theme gets included in GUI, but the color is chosen in reference to the GUI apps and history to NeXT * but if there are other suggestions for coloring the menu and other elements, and it can be agreed on, then it should be ;) * text alignment is justified * differentiate external links: those are marked with icon * News box on front page: * shows news on, releases, hackathons, papers, etc. * shows there is live in the community * New pages: hackathons page and papers page: * show there is live in the community * show there is fun in the community * make use of SSIs, to ease updating, at least for the top menu, and the dock at the bottom, and for example the news box on the front page * The screenshot pages should show off more Themes to underline GNUsteps flexibility in the look 'n feel Design
Re: GNUstep.org website redesign proposal
Sebastian and whoever else is interested in this discussion, I've been following the discussions over the last few weeks but I haven't felt the need to chime in until now. I looked at your example and read through most of your explanation (I must admit, I didn't read it all). I like the general look, and I think it looks much better than the current website look. However, I do not think the dock at the bottom is relevant--there are no such docks available for GNUstep applications. In addition, I'm currently on vacation on only have my tablet, with this interface I can't actually hover over the icons at the bottom and had no idea what they were until after I clicked on them. Nowadays, you need to consider that this is an use case and must cater to people on tablets as well as on desktops. I like the idea of modeling against the gtk.org website, as GNUstep caters to a lot of the same developers. All this said, I think the first thing we must do first is define what is going to be included as proper GNUstep. What are we going to include of the Documentation menu? Obviously GNUstep-make, -base, -gui and -back are going to have documentation, but what else? Is libobjc2 considered proper GNUstep? If so, shouldn't it's documentation be prominently displayed, as well? What other projects will be linked from the website? Richard's EC and WebServer aren't currently mentioned anywhere on the website, only the wiki (at least, that I know of). If these side project are proper GNUstep, shouldn't they be integrated with the rest of the project? Additional thought: * Are we going to continue supporting Nikolaus' Software Index? If so, how can that be better integrated with the new website? The current design looks very foreign. Is it even something that we will continue to support? Overall, I think the design is good and I would support the effort in whatever way I can (I know absolutely nothing about HTML or CSS, but can help with content and structure). On Dec 30, 2013 8:10 PM, Sebastian Reitenbach sebas...@l00-bugdead-prods.de wrote: Hi all, I guess everybody knows, and also agrees that the GNUstep website is looking fairly dated, and that finding contents in it, is somtetimes only possible with help of google. the last few days I spent on thinking about the website, what it may need, digging html5 and css3, and came up with the following design, that you can find here: https://www.l00-bugdead-prods.de/index7.html Note, not all pages and links are implemented. I did not wanted to waste too much time, in case, the majority of people doesn't like with what I've come up. Older revisions, that finally lead to the design I have now, can be seen here: https://www.l00-bugdead-prods.de/index3.html https://www.l00-bugdead-prods.de/index5.html https://www.l00-bugdead-prods.de/index6.html The major design goals of the page are: * have a half way modern look, but don't overdo * easy and logical menu structuring, it should be easy to find things following a logic Further Ideas and things I had considered while designing were: Intended main audience: * MAC Developers seeking to port their apps to other platforms * Developers from other platforms, seeking to base their projects, commercial or free, on GNUstep * Packagers, that want to package GNUstep for their favourite OS/Distribution Not intended main audience, but also welcomed: * End users of any kind * direct End users to the pages to GWorkspace or SystemPreferences, Example applications, and screenshots * otherwise, direct end users to GAP and maybe other external sites Why chose the main audience above? * GNUstep is a set of libraries, providing an API to be used by developers * libraries are accompanied by a set of development tools * GWorkspace and SystemPreferences are nice show cases for developers that want to get to know what they can get from GNUstep General design goals of the page: * Its generally intended to attract the main intended audience * have a modern look and feel, but keep the page simple * page should work with recent modern browsers * making use of modern HTML5 and CSS3 * page may look a bit odd with old browsers (this likely includes SWK ;) * but who is really using a browser that does not understand HTML5/CSS3, or at least a subset of it? Even Google doesn't support old browsers. * simple wording, short and clear sentences * simple page structure, simulating the MAC Desktop * main menu (the dock at the bottom on every page) * always all the time visible * horizontal menu on the top dependent on what's chosen from the dock at the bottom * the icon on the left shows which menu entry was chosen from the dock at the bottom Some more specific design decisions are based on: * design of the contents of the homepage: * do not overload with information or images, the page should load fast ;) * address the most interesting
Wiki (was Re: GNUstep.org website redesign proposal)
El mar, 31-12-2013 a las 02:09 +0100, Sebastian Reitenbach escribió: Hi all, [..] * maybe trash the wiki.gnustep.org * its unmaintainable, contains lots of outdated, incorrect and misleading information * incorporate important information into the main website OR someone (or a team) needs to be willing to review it regularly and if necessary clean it up/update outdated info there I think the wiki is important, we just need invite people to update and write. In other way, if we put all at main website, this will be a lot of work for whichever is the maintainer. And with the time this will become outdated. I suggest, remove the news from wiki, and add a main page with some information about what is available at wiki. Like, for example, GNU Octave wiki (http://wiki.octave.org/Main_Page) or Emacs wiki (http://www.emacswiki.org/). And, since we have Software Index, we can remove all the apps at wiki. Because this is a duplicated effort. If you are agree, I can help in this way. Even with the recording of some video tutorials to show some basics examples. And put this at http://www.mediagoblin.com/ or at http://gobblin.se/ Regards. Germán. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
On 30 Dec 2013, at 10:26, David Chisnall thera...@sucs.org wrote: On 30 Dec 2013, at 07:23, Richard Frith-Macdonald richardfrithmacdon...@gmail.com wrote: In my experience CMake is far more of a burden because it doesn't have the years of documentation development that autoconf has, and (more importantly to me) because its a monolithic C program. You need to get the source and figure out what it's doing, and that's just easier to do with the configure script and macros in autoconf. This is simply not true. The vast majority of the logic of cmake is in the .cmake files. The 'monolithic C program' (which is written in C++) is just the interpreter. Large library projects typically distribute their own .cmake files containing specific rules for their build systems, but these compose with other rules. For example, LLVM ships a bunch of .cmake files, which libobjc2 uses when building the LLVM optimisation passes. Qt, KDE, and so on all ship custom .cmake files that simplify building apps for those platforms. I don't think I've ever looked at the source for CMake, though I use it for a number of projects - I've always found what I needed to do by either reading the documentation or searching their mailing list archives. Sorry for saying 'C' rather than 'C++'; didn't know that such sloppiness would offend. I looked at the source (rather than trying to find things on mailing lists) because the documentation for cmake is much less mature than that for autoconf. Yes there are rules files, but again documentation is less good/mature than that of the standard m4 macro language and shell scripts used by autoconf. I'm not sayingm there's a big difference between the two systems, just that the age difference means that it's less hard to find solutions to maintain a project using the older one. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
On Mon, Dec 30, 2013 at 2:26 AM, David Chisnall thera...@sucs.org wrote: On 30 Dec 2013, at 07:23, Richard Frith-Macdonald richardfrithmacdon...@gmail.com wrote: In my experience CMake is far more of a burden because it doesn't have the years of documentation development that autoconf has, and (more importantly to me) because its a monolithic C program. You need to get the source and figure out what it's doing, and that's just easier to do with the configure script and macros in autoconf. This is simply not true. The vast majority of the logic of cmake is in the .cmake files. The 'monolithic C program' (which is written in C++) is just the interpreter. Large library projects typically distribute their own .cmake files containing specific rules for their build systems, but these compose with other rules. For example, LLVM ships a bunch of .cmake files, which libobjc2 uses when building the LLVM optimisation passes. Qt, KDE, and so on all ship custom .cmake files that simplify building apps for those platforms. I don't think I've ever looked at the source for CMake, though I use it for a number of projects - I've always found what I needed to do by either reading the documentation or searching their mailing list archives. My main attraction to CMake, however, is not CMake itself as much as Ninja, which dramatically improves life when doing a lot of incremental builds. LLVM has both CMake and autoconf+make build systems. After changing one file, the Ninja files that CMake generates can do an incremental build in less time than it takes for the GNU Make build system to determine that it has no work to do if you don't change any files. Oh, and when it needs to reconfigure, rerunning cmake takes about a fifth of the time that running ./configure takes, even though it's actually doing more work (configure just sets some flags for some hand-written Makefiles to use, cmake generates the build system). Yes it might be faster than autoconf/automake but it is less standardized things to do in cmake. I have played around with a cmake system in the last year and found it was horrible as the options that I needed to do for cross compiling was all different and did not always do the correct thing so I had to hack the files instead. autoconfig/automake has some nice standardized way of figuring out if an API and/or a library exists. When was the last time you did a cross of a library that was not autoconf'd? cmake was not designed for cross compiling or even fits in a GNU project. Yes autoconf has its issue (slow due to being a big shell script) but being slow helps the portability of it. Try building cmake itself, it is a hard thing to do really; worse than GCC. Thanks, Andrew Pinski For OS X users, there's a nice CMake GUI that lets you generate XCode project files, which I imagine would be very attractive to users wanting to run GNUstep code on that platform. The generated XCode files aren't perfect, but they're a lot easier for OS X developers to use than GNUstep Make. Oh, and they already support building .app and .framework bundles on OS X, so it should be possible to reuse some of this code, which might even give us some existing OS X applications running on GNUstep for free... That said, I completely agree with Fred, that there's no point discussing a change of build system without at least a proof of concept demonstration that another one would work. I would, however, suggest that this would be much easier to do if we had some documentation describing things like the various filesystem / bundle layouts. David -- Sent from my Cray X1 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
El lun, 30-12-2013 a las 16:48 -0200, Jamie Ramone escribió: Hmm, interesting. What could be a good workaround? Can it safely be removed or downgraded? Keep in mind that I'm on Ubuntu 12.04. I'm not sure, but this could be a problem in the version of libc that has Ubuntu 12.04. Unfortunately there isn't an update for this package in 12.04. I only can think to test it (maybe in a virtual machine) with a more recent version of Ubuntu. Germán. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
