Cross-compiling GNUstep?
Hello everyone, I'm trying to cross-compile GNUstep, and since I'm sure I'm not the first person to try this, I wondered if anyone had written up how to do it? I am trying to build from FreeBSD/amd64 for FreeBSD/MIPS64. I have a cross-compiler and sysroot setup. Building the runtime was trivial - just point cmake at the cross-compile toolchain file - what do I need to do for Make / base so that: - It knows that I don't actually want -make on the target platform. - I get an installed version somewhere on my local machine that I can copy to a different location on the remote - All of the correct cross-compile flags are passed to the compiler I think Ivan has been through all of this recently for Android? David -- This email complies with ISO 3103 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
On 29.12.2013 13:56, David Chisnall wrote: > Hello everyone, > > I'm trying to cross-compile GNUstep, and since I'm sure I'm not the first > person to try this, I wondered if anyone had written up how to do it? I am > trying to build from FreeBSD/amd64 for FreeBSD/MIPS64. I have a > cross-compiler and sysroot setup. Building the runtime was trivial - just > point cmake at the cross-compile toolchain file - what do I need to do for > Make / base so that: > > - It knows that I don't actually want -make on the target platform. > - I get an installed version somewhere on my local machine that I can copy to > a different location on the remote > - All of the correct cross-compile flags are passed to the compiler > > I think Ivan has been through all of this recently for Android? Hi David, you probably know about our wiki page on this subject http://wiki.gnustep.org/index.php/Cross_Compiling that isn't all that helpful. I tried to cross compile GNUstep myself years ago but failed in that attempt. The two biggest issues I remember where the configure scripts and GNUstep make. We rely heavily on our configure scripts to figure out how GNUstep core components should be compiled. The best thing you can do is copy the configure scripts over to the target system and try to run them there. Of course this requires all the development tools to be installed there as well. You then have the resulting configuration files (different ones for each component when I remember correctly) that you copy back to the cross-compilation environment. You could of course rely on autoconf to sort things out for you, but it didn't work for me or try to guess everything yourself :-( The problem with GNUstep make as I remember it was that it had a somewhat different view of the host/build/target triple than any other cross compilation system I know of. As a result helper tools get compiled for the target environment but will get run during the build. The best instructions I can find at the moment are in the INSTALL file of make. Hope this helps, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
I managed to get -base cross-compiled, at least. I had to hack the GNUmakefile, because even when I tell it that it's cross compiling for a modern runtime, it correctly defines the OBJC2RUNTIME thing in the features header, but not in the GNUmakefile. I couldn't manage to persuade our autoconf stuff to pass the required [OJB]C[XX]FLAGS when trying to build things, so I had to make little wrapper scripts that invoked clang[++] with the required arguments (-B, --sysroot, -target, and so on). Note that poor cross-build support makes supporting embedded platforms difficult, and embedded these days can easily mean 1GHz CPU and 256MB of RAM. Unfortunately, this appears to be part of the legacy of autotools / GNUstep Make. David On 29 Dec 2013, at 15:20, Fred Kiefer wrote: > On 29.12.2013 13:56, David Chisnall wrote: >> Hello everyone, >> >> I'm trying to cross-compile GNUstep, and since I'm sure I'm not the first >> person to try this, I wondered if anyone had written up how to do it? I am >> trying to build from FreeBSD/amd64 for FreeBSD/MIPS64. I have a >> cross-compiler and sysroot setup. Building the runtime was trivial - just >> point cmake at the cross-compile toolchain file - what do I need to do for >> Make / base so that: >> >> - It knows that I don't actually want -make on the target platform. >> - I get an installed version somewhere on my local machine that I can copy >> to a different location on the remote >> - All of the correct cross-compile flags are passed to the compiler >> >> I think Ivan has been through all of this recently for Android? > > Hi David, > > you probably know about our wiki page on this subject > http://wiki.gnustep.org/index.php/Cross_Compiling > that isn't all that helpful. > > I tried to cross compile GNUstep myself years ago but failed in that > attempt. The two biggest issues I remember where the configure scripts > and GNUstep make. We rely heavily on our configure scripts to figure out > how GNUstep core components should be compiled. The best thing you can > do is copy the configure scripts over to the target system and try to > run them there. Of course this requires all the development tools to be > installed there as well. You then have the resulting configuration files > (different ones for each component when I remember correctly) that you > copy back to the cross-compilation environment. You could of course rely > on autoconf to sort things out for you, but it didn't work for me or try > to guess everything yourself :-( > > The problem with GNUstep make as I remember it was that it had a > somewhat different view of the host/build/target triple than any other > cross compilation system I know of. As a result helper tools get > compiled for the target environment but will get run during the build. > > The best instructions I can find at the moment are in the INSTALL file > of make. > > Hope this helps, > Fred > > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev -- Send from my Jacquard Loom ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
Am 29.12.2013 17:06, schrieb David Chisnall: > Unfortunately, this appears to be part of the legacy of autotools / GNUstep > Make. My impression is, GNUstep make tries to offer a very similar level of abstraction at runtime of what autoconf does at ./configure time. What to do? Drop GNUstep Make and depend entirely on autotools? 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?
By no means do I claim to have done things the right way, but it seems that work that I did plus work based on Emmanuel's patches did things right for Android. It may be worth looking through my commits around April and May 2013 into -make and -base. Then look at: http://bitbucket.org/ivucica/gnustep-android/ I never completed the work, but I tried it Thursday and: - nonupstreamed patches failed to apply due to changes in GNUstep - there was a linker error, IIRC with sysinfo(), probably because Bionic doesn't expose that. There have been some warnings and errors from configure scripts mentioning that I am incorrectly trying to cross-compile but I didn't look into that closely yet. IIRC there wasn't much need for deep 'hacking' of the build process itself (otherwise I wouldn't try to upstream it; Emmanuel's patches tried to hack a lot of things which is why they could not be applied -- they'd break other platforms). On 29 Dec 2013 16:06, "David Chisnall" wrote: > I managed to get -base cross-compiled, at least. I had to hack the > GNUmakefile, because even when I tell it that it's cross compiling for a > modern runtime, it correctly defines the OBJC2RUNTIME thing in the features > header, but not in the GNUmakefile. > > I couldn't manage to persuade our autoconf stuff to pass the required > [OJB]C[XX]FLAGS when trying to build things, so I had to make little > wrapper scripts that invoked clang[++] with the required arguments (-B, > --sysroot, -target, and so on). > > Note that poor cross-build support makes supporting embedded platforms > difficult, and embedded these days can easily mean 1GHz CPU and 256MB of > RAM. Unfortunately, this appears to be part of the legacy of autotools / > GNUstep Make. > > David > > On 29 Dec 2013, at 15:20, Fred Kiefer wrote: > > > On 29.12.2013 13:56, David Chisnall wrote: > >> Hello everyone, > >> > >> I'm trying to cross-compile GNUstep, and since I'm sure I'm not the > first person to try this, I wondered if anyone had written up how to do it? > I am trying to build from FreeBSD/amd64 for FreeBSD/MIPS64. I have a > cross-compiler and sysroot setup. Building the runtime was trivial - just > point cmake at the cross-compile toolchain file - what do I need to do for > Make / base so that: > >> > >> - It knows that I don't actually want -make on the target platform. > >> - I get an installed version somewhere on my local machine that I can > copy to a different location on the remote > >> - All of the correct cross-compile flags are passed to the compiler > >> > >> I think Ivan has been through all of this recently for Android? > > > > Hi David, > > > > you probably know about our wiki page on this subject > > http://wiki.gnustep.org/index.php/Cross_Compiling > > that isn't all that helpful. > > > > I tried to cross compile GNUstep myself years ago but failed in that > > attempt. The two biggest issues I remember where the configure scripts > > and GNUstep make. We rely heavily on our configure scripts to figure out > > how GNUstep core components should be compiled. The best thing you can > > do is copy the configure scripts over to the target system and try to > > run them there. Of course this requires all the development tools to be > > installed there as well. You then have the resulting configuration files > > (different ones for each component when I remember correctly) that you > > copy back to the cross-compilation environment. You could of course rely > > on autoconf to sort things out for you, but it didn't work for me or try > > to guess everything yourself :-( > > > > The problem with GNUstep make as I remember it was that it had a > > somewhat different view of the host/build/target triple than any other > > cross compilation system I know of. As a result helper tools get > > compiled for the target environment but will get run during the build. > > > > The best instructions I can find at the moment are in the INSTALL file > > of make. > > > > Hope this helps, > > Fred > > > > > > > > ___ > > Gnustep-dev mailing list > > Gnustep-dev@gnu.org > > https://lists.gnu.org/mailman/listinfo/gnustep-dev > > > > -- Send from my Jacquard Loom > > > ___ > 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: Cross-compiling GNUstep?
On 29 Dec 2013, at 17:09, Markus Hitter wrote: > My impression is, GNUstep make tries to offer a very similar level of > abstraction at runtime of what autoconf does at ./configure time. What > to do? Drop GNUstep Make and depend entirely on autotools? I'd be more inclined to move to CMake, which has the advantage of not being a complete usability disaster and being able to generate XCode projects. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
Am 29.12.2013 19:47, schrieb David Chisnall: > I'd be more inclined to move to CMake, which has the advantage of not being a > complete usability disaster and being able to generate XCode projects. While I have no experience with CMake, I wouldn't mind either. I just see my shiny new Debian packages don't allow me to build -base without debian/rules. configure insists to run on a normal make and falls back to the non-fhs layout. The whole testsuite ignores messages=yes, apparently all the checks fail silently. Building a single one doesn't work either, "Testing.h" not found. Have yet to investigate what actually happens, but it's obvious GNUstep Make isn't exactly bullet-proof. How could backward compatibility work? I already see "it has served us well for 15 years and I don't want to re-write all my projects" ... 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?
CMake would be great. LLVM/Clang already use it. It can generate ninja build files. It shows what it is doing with ccmake. It should make cross compiling more straight forward. And libobjc2 already uses it. hehe I tried working with those config files in base last year and found them very frustrating, refering to code and options that seemed many years old and unsupported. On Sun, Dec 29, 2013 at 1:47 PM, David Chisnall wrote: > On 29 Dec 2013, at 17:09, Markus Hitter wrote: > > > My impression is, GNUstep make tries to offer a very similar level of > > abstraction at runtime of what autoconf does at ./configure time. What > > to do? Drop GNUstep Make and depend entirely on autotools? > > I'd be more inclined to move to CMake, which has the advantage of not > being a complete usability disaster and being able to generate XCode > projects. > > David > > > ___ > 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: Cross-compiling GNUstep?
On 29.12.2013 20:17, Markus Hitter wrote: > Am 29.12.2013 19:47, schrieb David Chisnall: >> I'd be more inclined to move to CMake, which has the advantage of not being >> a complete usability disaster and being able to generate XCode projects. > > While I have no experience with CMake, I wouldn't mind either. > > I just see my shiny new Debian packages don't allow me to build -base > without debian/rules. configure insists to run on a normal make and > falls back to the non-fhs layout. The whole testsuite ignores > messages=yes, apparently all the checks fail silently. Building a single > one doesn't work either, "Testing.h" not found. Have yet to investigate > what actually happens, but it's obvious GNUstep Make isn't exactly > bullet-proof. > > How could backward compatibility work? I already see "it has served us > well for 15 years and I don't want to re-write all my projects" ... Should I step in here? Looks like a nice trap, doesn't it? Oh yes, I will try it. In you last mail you wrote "My impression is, GNUstep make tries to offer a very similar level of abstraction at runtime of what autoconf does at ./configure time.". No this is not what GNUstep make is trying to do. This is what we use autoconf and the generate configure file for. cmake seems to be addressing both the functionality of autoconf and GNUstep make at once. Maybe this is a good approach, I don't know and I wasn't able to find out. I skimmed over the FAQ at the cmake web site to find out about the features cmake is offering, but it didn't tell me that much. The first question that we should be asking us is what GNUstep make actually offers and how this could be replaced if we really want to replace it. GNUstep make is a tiny expansion of GNU make that allows to write more compact make files for Objective-C applications. It doesn't try to save the world and it surely has a few bugs. Now I had a few problem myself over this weekend with GNustep make. What did I do to resolve them? Suggest to switch to some new software? Or just go don't into the GNUstep make stuff and fix things? GNUstep make definitely isn't perfect. We left it to bit rot for some time. Still it is doing a lot of useful stuff which is hard to replace. I am rather sure that it would be possible to reproduce most of the features of GNUstep make with cmake and my question is not so much about the few missing case. But who would be willing to rewrite the whole of GNUstep make in cmake and guarantee full functionality? About four years ago David started to write a new libobjc based on code that was already in Etoile and with the old GNU libobjc as guideline. I would say that he is an extraordinary programmer. Still only about now would I suggest to use it on ARM or MIPS platforms. What does this tell us? Writing great software is hard, writing great software that works in environment that you yourself normally don't use is even harder. Yes, I totally agree that GNUstep make plus our configure files are very hard to use in a cross compilation case. Requesting that we throw it away and replace it by cmake would at least require a proof of concept implementation of a cmake configuration for the GNUstep core components that works flawless on let's say three Linux, two BSD and one Windows platform. If you are willing to provide that. I am going to help with testing and correcting it. And maybe in four years time we have something to replace GNUstep make. Up to then I will have to keep on fixing GNUstep make. Fred PS: The error you are getting with "Testing.h" suggest that you either did not install GNUstep make or didn't source the GNUstep.sh file. And "messages=yes make check" followed by "less tests.log" should give you more output that you ever would like to read through. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
Am 29.12.2013 23:11, schrieb Fred Kiefer: > On 29.12.2013 20:17, Markus Hitter wrote: >> Am 29.12.2013 19:47, schrieb David Chisnall: >>> I'd be more inclined to move to CMake, which has the advantage of not being >>> a complete usability disaster and being able to generate XCode projects. >> >> While I have no experience with CMake, I wouldn't mind either. [...] >> How could backward compatibility work? I already see "it has served us >> well for 15 years and I don't want to re-write all my projects" ... > > Should I step in here? You do and, wow, what a lengthy one. > The first question that we should be asking us is what GNUstep make > actually offers This is exactly the question to answer. And also, wether these advantages are important enough to justify maintaining a distinct build system. Because at the bottom line and unless I'm totally mistaken, Obj-C is compiled the same way as C, C++ and most other compiled languages. Accordingly, many other build tools should work just as fine. Could you elaborate a bit on these advantages of GNUstep Make? > Writing great software is hard, writing great software that works in > environment that you yourself normally don't use is even harder. Unlike libobjc2 four years ago, CMake is written already and known to work well. Accordingly, it should not be an additional burden, but a relief from some hard work. Once setup, others maintain all the build tools, GNUsteppers can concentrate on Obj-C. I'm well aware it's hard to abandon stuff one has worked on for years. But my experience is, every few years one should re-evaluate wether a competitor was much much better/faster and wether it still makes sense to continue with the own efforts. IF this evaluates to a small amount of sense, only, archiving existing stuff and enjoying the shrunken code base (less maintenance work! fewer chances for bugs!) is the right way to go. > Yes, I totally agree that GNUstep make plus our configure files are very > hard to use in a cross compilation case. Requesting that we throw it > away and replace it by cmake would at least require a proof of concept > implementation of a cmake configuration for the GNUstep core components > that works flawless on let's say three Linux, two BSD and one Windows > platform. I think the idea of CMake is to write build instructions once, then to deploy "everywhere". Unix Makefiles, MinGW Makefiles, Xcode, whatever. CMake comes with sort of compilers to allow everybody to extract something usable for his favourite environment. This extraction wouldn't be part of GNUstep, however. > And "messages=yes make check" followed by "less tests.log" should give you > more output Aaah, messages are redirected into a file. Thanks for the hint! Now I see it works better than I thought previously. Many of the tests work, while quite a bunch in -gui fail due to a missing backend (no surprise). "make" or "make check" doesn't work in the individual tests, but when run from Tests/ . Cheers, 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 29 Dec 2013, at 19:17, Markus Hitter wrote: > Am 29.12.2013 19:47, schrieb David Chisnall: >> I'd be more inclined to move to CMake, which has the advantage of not being >> a complete usability disaster and being able to generate XCode projects. > > While I have no experience with CMake, I wouldn't mind either. 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. > 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. > configure insists to run on a normal make and > falls back to the non-fhs layout. I think you are talking about the case where the software hasn't been configured; you type make, and the configure script is automatically run. That's nothing directly to do with either autoconf or gnustep-make. Rather it's a deliberate feature provided by the makefiles of many (most?) projects ... if you try to build a project without having run the configure script since it was last modified, there's a makefile rule to run configure for the project (keeping any existing selected options) on your behalf (another common thing for makefiles to do is print an error message saying you haven't configured the project, and then bomb out). When you fist build a project, you are expected to run the configure script before building (with cmake, you do the same thing and run cmake before building) specifying the options you want (like the debian/fhs layout). > The whole testsuite ignores > messages=yes, The testsuite doesn't have a 'messages=yes' option... that's a gnustep-make option, not a test framework option. The test framework is a few header files and shell scripts and some documentation/examples, packaged as an add-on to be installed with gnustep-make so it's available anywhere you might build software using gnustep-make. It's driven by the gnustep-tests shellscript/command (so it doesn't accept any make arguments) not a make file. Each testsuite is then a hierarchy of directories containing code fragments to be built/executed to perform tests, and a files to mark which directories actually contain test code. The gnustep-tests script runs the testsuite; when building a testcase from a fragment of source code, the script may generate a makefile to do the building, and you could then manually use that makefile supplying 'messages=yes' as an argument, but such a makefile would be so simple that it's hard to see the point. > apparently all the checks fail silently. Building a single > one doesn't work either, "Testing.h" not found. That sounds lke you don't have gnustep-make and/or the testute installed? Or don't have it installed in your PATH? Given that you implied above that you didn't configure gnustep-base to use the debian filesystem layout, I expect things are installed in the gnustep layout, so I'm further guessing that you didn't set up your environment to point to the gnustep installation (sourcing GNUstep.sh is the standard way to do that), and your problem most likelyh is that the gnustep-tests script can't find things, though I'd be interested in how/where you run gnustep-tests in that case. > Have yet to investigate > what actually happens, but it's obvious GNUstep Make isn't exactly > bullet-proof. I'm sure it's not ... but none of this sounds like gnustep-make issues. It does sound somewhat indirectly related to autoconf, in as much as it sounds like the problem is due to failure to configure, install, and set up the environment, but hard to say for sure. ___ 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 00:19, Markus Hitter wrote: > Am 29.12.2013 23:11, schrieb Fred Kiefer: >> On 29.12.2013 20:17, Markus Hitter wrote: >>> Am 29.12.2013 19:47, schrieb David Chisnall: I'd be more inclined to move to CMake, which has the advantage of not being a complete usability disaster and being able to generate XCode projects. >>> >>> While I have no experience with CMake, I wouldn't mind either. > [...] >>> How could backward compatibility work? I already see "it has served us >>> well for 15 years and I don't want to re-write all my projects" ... >> >> Should I step in here? > > You do and, wow, what a lengthy one. > > >> The first question that we should be asking us is what GNUstep make >> actually offers > > This is exactly the question to answer. And also, wether these > advantages are important enough to justify maintaining a distinct build > system. Because at the bottom line and unless I'm totally mistaken, > Obj-C is compiled the same way as C, C++ and most other compiled > languages. Accordingly, many other build tools should work just as fine. > > Could you elaborate a bit on these advantages of GNUstep Make? GNUstep-make is really just gnumake plus some additional structure/conventions (encapsulated in a set of make file fragments included into your project's make file) ... rather like the relationship between ObjC and C. So you can put anything from a 'normal' makefile into a gnustep make file. What makes it special are the conventions/knowledge built into it; knowledge about the different project types (command line tools, apps, libraries, frameworks), what is included with them plists etc, where they should be installed all that sort of stuff. All this knowledge is like the build-in rule in standard make that tells it how to make a .o file from a .c file (invoke the compiler with certain flags using the correct fiel names), but deals with correct linker commands, libraries, resources and where everything should go and how it should be installed. It means that the vast majority of projects essentially need to do no more than declare a few variables listing the source files used. Other projects mostly might want to add dependencies on external libraries etc, so there are variables for plugging those into all the standard rules. For the very few cases (eg libobjc2) where you are actually building something almost completely outside gnustep, then it makes sense to fall back on vanilla make rules, just using the gnustep-make rules to decide where to install the result. In these cases gnustep-make offers very little of course. >> Writing great software is hard, writing great software that works in >> environment that you yourself normally don't use is even harder. > > Unlike libobjc2 four years ago, CMake is written already and known to > work well. Accordingly, it should not be an additional burden, but a > relief from some hard work. Once setup, others maintain all the build > tools, GNUsteppers can concentrate on Obj-C. If only that were true. I guess CMake is known to work well, but that's in the same sense that autoconf/automake is known to work well. When they don't do what you want, both are horrid. 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. I guess in both cases, if you are familiar enough with them they are fine, but I don't spend all my time hacking configuration systems, so I'm perpetually unfamiliar with either. I'm also dubious about CMake's ability to integrate to GNUstep at the makefile level; With autoconf/automake we simply don't use automake, and have autoconf generate .h and .make file fragments to use in the build process. With CMake the configure/build processes are more tightly coupled ... if we can't do a similar solution then we'd probably need to hack on the CMake program itsself and maybe fork it ... making it far more work to maintain than what we have now. It's hard to see how CMake could possibly help letting us concentrate on ObjC rather than build tools, when the maintainers of CMake are no more likely to cater for GNUstep than the maintainers of autoconf/automake are. We'd just have a different project we need to supply patches to. But I guess that was Fred's point really. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
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 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: Cross-compiling GNUstep?
Am 30.12.2013 08:23, schrieb Richard Frith-Macdonald: > >> Could you elaborate a bit on these advantages of GNUstep Make? > > GNUstep-make is really just gnumake plus some additional > structure/conventions (encapsulated in a set of make file fragments > included into your project's make file) ... rather like the > relationship between ObjC and C. So you can put anything from a > 'normal' makefile into a gnustep make file. > > What makes it special are the conventions/knowledge built into it; > knowledge about the different project types (command line tools, > apps, libraries, frameworks), what is included with them plists etc, > where they should be installed all that sort of stuff. All this > knowledge is like the build-in rule in standard make that tells it > how to make a .o file from a .c file (invoke the compiler with > certain flags using the correct fiel names), but deals with correct > linker commands, libraries, resources and where everything should go > and how it should be installed. > > It means that the vast majority of projects essentially need to do no > more than declare a few variables listing the source files used. > > Other projects mostly might want to add dependencies on external > libraries etc, so there are variables for plugging those into all the > standard rules. Thanks. > I'm also dubious about CMake's ability to integrate to GNUstep at the > makefile level; With autoconf/automake we simply don't use automake, > and have autoconf generate .h and .make file fragments to use in the > build process. With CMake the configure/build processes are more > tightly coupled ... if we can't do a similar solution then we'd > probably need to hack on the CMake program itsself and maybe fork it > ... making it far more work to maintain than what we have now. CMake doesn't integrate, it's put on top of makefiles. Creating makefiles is just one of many options to build with CMake. One disadvantage of GNUstep Make is, it uses a language (in form of variables to be defined) which is used by GNUstep, only. automake or CMake would help here extending the user base (10-fold?) if it's possible to extend them to Obj-C _without_ adding more language. Doesn't help with all the Xcode/CodeBlocks/Eclipse users, though, because by default they invoke neither of GNUstep Make, automake or CMake to build their stuff. To sum up, I don't see a golden solution either. It's more like thinking loudly. 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?
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: Cross-compiling GNUstep?
Hi, Markus Hitter wrote: 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 :-} the above sounds all fine to me and is similar to what I did when packaging RPMs. You "build" using always the previous compiled and installed dependency (RPMs have build dependencies vs. runtime dependencies). It all should work out of the box! If not there is something which can be improved. In the case of cross-compiling of course we have the problem that we do run tools (e.g. plmerge, pl2link). Those would need to be run as host and not target executables or they won't work. I wonder if this can possibly obtained and I don't think cmake would change things much Riccardo ___ 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 wrote: > On 30 Dec 2013, at 07:23, Richard Frith-Macdonald > 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 wrote: > On 30 Dec 2013, at 07:23, Richard Frith-Macdonald > 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: Cross-compiling GNUstep?
On 29 Dec 2013, at 12:56, David Chisnall wrote: > Hello everyone, > > I'm trying to cross-compile GNUstep, and since I'm sure I'm not the first > person to try this, I wondered if anyone had written up how to do it? I am > trying to build from FreeBSD/amd64 for FreeBSD/MIPS64. I have a > cross-compiler and sysroot setup. Building the runtime was trivial - just > point cmake at the cross-compile toolchain file - what do I need to do for > Make / base so that: > > - It knows that I don't actually want -make on the target platform. > - I get an installed version somewhere on my local machine that I can copy to > a different location on the remote > - All of the correct cross-compile flags are passed to the compiler > > I think Ivan has been through all of this recently for Android? Going back to the start of thread (since it seems to have gone completely off topic), I took a quick look at the documentation (radical concept eh). The gnustep-make README document says (in the first introductory paragraph) that it supports cross compilation. The gnustep-make INSTALL document has a section on it and gives an example: ./configure --target=i386-mingw32 make install Now, I've never done any cross compilation, and probably most other people don't do it eiother, so I don't know if cross compilation support has bit-rotted, support for cross-compiling for a particular target is certainly there, ad this (the --target= option) appears to be the standard mechanism (a web search for cross compiling and autoconf finds it immediately). I guess the answer (howto do it) is that you configure for the target OS/CPU you want, then just build as normal. The INSTALL documentation also explains about using a non-flattened layout if you want to have multple architectures in the same filesystrem hierarchy etc. Of course, if there are any bit-rotted makefiles, we should correct them and make a bugfix release of the affected package. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
For Android I have been passing ./configure --host=arm-linux-androideabi. It's mentioned by configure itself. --target does look like the correct way to do it. The whole thing is slightly confusing and needs to be read a couple of times to be understood. So I did just that: http://stackoverflow.com/a/15901574/39974 http://stackoverflow.com/a/5139451/39974 On Wed Jan 01 2014 at 3:25:19 PM, Richard Frith-Macdonald < richardfrithmacdon...@gmail.com> wrote: > > On 29 Dec 2013, at 12:56, David Chisnall wrote: > > > Hello everyone, > > > > I'm trying to cross-compile GNUstep, and since I'm sure I'm not the > first person to try this, I wondered if anyone had written up how to do it? > I am trying to build from FreeBSD/amd64 for FreeBSD/MIPS64. I have a > cross-compiler and sysroot setup. Building the runtime was trivial - just > point cmake at the cross-compile toolchain file - what do I need to do for > Make / base so that: > > > > - It knows that I don't actually want -make on the target platform. > > - I get an installed version somewhere on my local machine that I can > copy to a different location on the remote > > - All of the correct cross-compile flags are passed to the compiler > > > > I think Ivan has been through all of this recently for Android? > > Going back to the start of thread (since it seems to have gone completely > off topic), I took a quick look at the documentation (radical concept eh). > The gnustep-make README document says (in the first introductory > paragraph) that it supports cross compilation. > The gnustep-make INSTALL document has a section on it and gives an example: > > ./configure --target=i386-mingw32 > make install > > Now, I've never done any cross compilation, and probably most other people > don't do it eiother, so I don't know if cross compilation support has > bit-rotted, support for cross-compiling for a particular target is > certainly there, ad this (the --target= option) appears to be the standard > mechanism (a web search for cross compiling and autoconf finds it > immediately). > > I guess the answer (howto do it) is that you configure for the target > OS/CPU you want, then just build as normal. The INSTALL documentation also > explains about using a non-flattened layout if you want to have multple > architectures in the same filesystrem hierarchy etc. > > Of course, if there are any bit-rotted makefiles, we should correct them > and make a bugfix release of the affected package. > ___ > 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
Android (Was: Cross-compiling GNUstep?)
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 configure, so it was throwing errors around. This has been fixed by introducing ENABLE_OPENSSL variable in a couple of places (as opposed to HAVE_OPENSSL, since this relates solely to flag being passed; it is my understanding that further detection is being done in the SSL/ directory's configure) and slightly cleaning up the relevant part of configure.ac. <- This introduced patch numbered 03. Third, -base's make install failed because gdomap could not be built. As it is useless for Android anyway, in case Android is being targeted (GNUSTEP_TAGET_OS linux-androideabi), no longer is subproject Tools appended to the appropriate library. Neither are NSTimeZones, Resources and Tests; solely because it makes little sense to build anything relating to resources or to run tests while cross compiling. On Android, we'll have to deal with any resource loading in a different way, anyway, so whatever is in Resources/ and NSTimeZones/ can be skipped for now. <- This introduced patch numbered 04. Fourth, to make thegrandexperiment work, I've switched to android-14. (android-8 doe
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 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
Re: Android (Was: Cross-compiling GNUstep?)
Hi David, On Mon Dec 30 2013 at 10:27:18 AM, David Chisnall 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 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: Android (Was: Cross-compiling GNUstep?)
One thing of note is currently LTO doesn't work on clang with the NDK. Looks like when we went through the same exercise as Ivan it was not using cmake but the raw makefile and I have this change: --Wl,-soname=$(LIBOBJCXX).so.$(MAJOR_VERSION) $(LDFLAGS) \ +-Wl,-soname=$(LIBOBJCXX).so $(LDFLAGS) -ldispatch \ in git. Not the best change but we were trying a lot of different things. Having a repeatable easy to build libobjc2/gnustepbase/corebase on Android would be a big win. On Mon, Dec 30, 2013 at 3:50 AM, David Chisnall wrote: > > On 30 Dec 2013, at 10:58, Ivan Vučica 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 > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Android (Was: Cross-compiling GNUstep?)
Nice work Ivan, some other thoughts from going through the same thing:
NativeActivity may be different, but in my case the thread that called
LoadLibrary is not used for me any more after that. This causes NSThread
MainThread to never be used though is set.
It would be nice to hook the activity through NSRunLoop, we never did and
just worked around it with categories where it was an issue.
What did you need API 14 for? We currently have API8 supported in the
store.
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 Sun, Dec 29, 2013 at 4:51 PM, Ivan Vučica 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 configure, so it was throwing errors
> around. This has been fixed by introducing ENABLE_OPENSSL variable in a
> coup
Re: Android (Was: Cross-compiling GNUstep?)
On 30 Dec 2013, at 16:32, Doug Warren 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: Android (Was: Cross-compiling GNUstep?)
First the good news: I am able to continue contributing to GNUstep outside of work. This means I've been able to push updated "gnustep-android" repository: https://bitbucket.org/ivucica/gnustep-android It should hopefully work with Ubuntu 12.04 out of the box. Looking forward to feedback! On Mon, Dec 30, 2013 at 4:32 PM, Doug Warren wrote: > Nice work Ivan, some other thoughts from going through the same thing: > > NativeActivity may be different, but in my case the thread that called > LoadLibrary is not used for me any more after that. This causes NSThread > MainThread to never be used though is set. > Template for NativeActivity does try to run all native code in non-main thread. So you are right that we need to play with setting the correct mainThread. > > It would be nice to hook the activity through NSRunLoop, we never did and > just worked around it with categories where it was an issue. > I've also had a need to hook some things for Core Animation, but never got around to hacking or studying -base enough to do it. > What did you need API 14 for? We currently have API8 supported in the > store. > Not sure by now. I think I've also had API8 set as target, but the OpenGL ES test code that I used required it for something. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Android (Was: Cross-compiling GNUstep?)
On Fri, Jan 17, 2014 at 9:45 PM, Ivan Vučica wrote: > First the good news: I am able to continue contributing to GNUstep outside > of work. > > This means I've been able to push updated "gnustep-android" repository: > https://bitbucket.org/ivucica/gnustep-android > > It should hopefully work with Ubuntu 12.04 out of the box. > > Looking forward to feedback! > > I've also dug out the (trivial!) sample application I put together to test that NSString from gnustep-base is being used: https://bitbucket.org/ivucica/thegrandexperiment -- Ivan Vučica i...@vucica.net ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
cross compiling gnustep on embedded device (wince)
Hi, I wanted to try to cross-compile core foundation to be able to play with objective C on my smartphone running windows CE. I am using cegcc as a cross compiler and I have downloaded : gnustep-make-2.2.0 gnustep-base-1.19.1 What would be the necessary steps to cross-compile and/or add support for wince platform ? First question is gnustep-make architecture dependent ? I have configured and compiled gnustep-make as shown below : ./configure --prefix=/opt/mingw32ce --host=arm-mingw32ce --target=arm-mingw32ce make && make instal THe problem I don't know if it handles cross-compiler and arm-*-pe targets ... Then I tried to configure gnustep-base but I get some errors that make me think that it uses wrong compiler (gcc instead of arm-mingw32ce-gcc ...) Could someone help me with this ? Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cross compiling gnustep on embedded device (wince)
On Fri, 25 Sep 2009 15:04:21 +0200, "Vincent R." wrote: > Hi, > > I wanted to try to cross-compile core foundation to be able to play with > objective C on > my smartphone running windows CE. > I am using cegcc as a cross compiler and I have downloaded : > > gnustep-make-2.2.0 > gnustep-base-1.19.1 > > What would be the necessary steps to cross-compile and/or add support for > wince platform ? > First question is gnustep-make architecture dependent ? > I have configured and compiled gnustep-make as shown below : > > ./configure --prefix=/opt/mingw32ce --host=arm-mingw32ce > --target=arm-mingw32ce > make && make instal > > THe problem I don't know if it handles cross-compiler and arm-*-pe targets > ... > > Then I tried to configure gnustep-base but I get some errors that make me > think > that it uses wrong compiler (gcc instead of arm-mingw32ce-gcc ...) > > Could someone help me with this ? What makes me think it uses teh wrong compiler is the following error : Making all for subproject Additions...z Compiling file GSCategories.m ... GSCategories.m: In function `-[NSData(GSCategories) initWithHexadecimalRepresentation:]': GSCategories.m:310: warning: subscript has type `char' GSCategories.m: At top level: GSCategories.m:945: error: conflicting types for 'strerror_r' /usr/include/string.h:69: error: previous declaration of 'strerror_r' was here GSCategories.m:945: error: conflicting types for 'strerror_r' /usr/include/string.h:69: error: previous declaration of 'strerror_r' was here it seems to search for include in /usr/include while it should be in /opt/mingw32ce/arm-mingw32ce/include Last thing how does makefile works because usually when I enter make command, make file is called and processed but here this is not the case since Makefile is almost empty. So how does it work ? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cross compiling gnustep on embedded device (wince)
OK I am progressing now I start to understand how makefiles works and now I have another error : Making all for subproject unix... Compiling file GSRunLoopCtxt.m ... GSRunLoopCtxt.m: In function '-[GSRunLoopCtxt dealloc]': GSRunLoopCtxt.m:84: error: '_efdMap' undeclared (first use in this function) GSRunLoopCtxt.m:84: error: (Each undeclared identifier is reported only once GSRunLoopCtxt.m:84: error: for each function it appears in.) GSRunLoopCtxt.m:88: error: '_rfdMap' undeclared (first use in this function) GSRunLoopCtxt.m:92: error: '_wfdMap' undeclared (first use in this function) GSRunLoopCtxt.m: In function '-[GSRunLoopCtxt endEvent:for:]': GSRunLoopCtxt.m:136: error: 'ET_RDESC' undeclared (first use in this function) GSRunLoopCtxt.m:137: error: '_rfdMap' undeclared (first use in this function) GSRunLoopCtxt.m:139: error: 'ET_WDESC' undeclared (first use in this function) GSRunLoopCtxt.m:140: error: '_wfdMap' undeclared (first use in this function) GSRunLoopCtxt.m:142: error: 'ET_EDESC' undeclared (first use in this function) GSRunLoopCtxt.m:143: error: '_efdMap' undeclared (first use in this function) GSRunLoopCtxt.m: In function '-[GSRunLoopCtxt initWithMode:extra:]': GSRunLoopCtxt.m:200: error: '_efdMap' undeclared (first use in this function) GSRunLoopCtxt.m:202: error: '_rfdMap' undeclared (first use in this function) GSRunLoopCtxt.m:204: error: '_wfdMap' undeclared (first use in this function) GSRunLoopCtxt.m: In function '-[GSRunLoopCtxt pollUntil:within:]': GSRunLoopCtxt.m:741: error: '_efdMap' undeclared (first use in this function) GSRunLoopCtxt.m:742: error: '_rfdMap' undeclared (first use in this function) GSRunLoopCtxt.m:743: error: '_wfdMap' undeclared (first use in this function) GSRunLoopCtxt.m:748: error: 'struct GSRunLoopThreadInfo' has no member named 'inputFd' GSRunLoopCtxt.m:776: error: 'ET_EDESC' undeclared (first use in this function) GSRunLoopCtxt.m:784: error: 'ET_RDESC' undeclared (first use in this function) GSRunLoopCtxt.m:792: error: 'ET_WDESC' undeclared (first use in this function) GSRunLoopCtxt.m:774: warning: enumeration value 'ET_HANDLE' not handled in switch GSRunLoopCtxt.m:774: warning: enumeration value 'ET_WINMSG' not handled in switch GSRunLoopCtxt.m:856: error: 'errno' undeclared (first use in this function) GSRunLoopCtxt.m:856: error: 'EINTR' undeclared (first use in this function) GSRunLoopCtxt.m:1011: error: 'struct GSRunLoopThreadInfo' has no member named 'inputFd' GSRunLoopCtxt.m: In function '+[GSRunLoopCtxt awakenedBefore:]': GSRunLoopCtxt.m:1080: error: 'struct GSRunLoopThreadInfo' has no member named 'inputFd' GSRunLoopCtxt.m:1080: error: 'struct GSRunLoopThreadInfo' has no member named 'inputFd' GSRunLoopCtxt.m:1081: error: 'struct GSRunLoopThreadInfo' has no member named 'inputFd' make[4]: *** [obj/GSRunLoopCtxt.m.o] Error 1 make[3]: *** [internal-subproject-all_] Error 2 Why is it compiling subproject unix ? Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cross compiling gnustep on embedded device (wince)
On 25 Sep 2009, at 16:57, Vincent R. wrote: Why is it compiling subproject unix ? This will have been set by the configure script. Did you set target triple when you ran ./configure? David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cross compiling gnustep on embedded device (wince)
On Fri, 25 Sep 2009 16:59:41 +0100, David Chisnall wrote: > On 25 Sep 2009, at 16:57, Vincent R. wrote: > >> Why is it compiling subproject unix ? > > This will have been set by the configure script. Did you set target > triple when you ran ./configure? > > David I did this : cd gnustep-base ./configure --prefix=/opt/mingw32ce --host=arm-mingw32ce --target=arm-mingw32ce --with-ffi-include=/opt/mingw32ce/lib/libffi-3.0.8/include --with-ffi-library=/opt/mingw32ce/lib make target=arm-mingw32ce shared=yes ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cross compiling gnustep on embedded device (wince)
On Fri, 25 Sep 2009 16:59:41 +0100, David Chisnall wrote: > On 25 Sep 2009, at 16:57, Vincent R. wrote: > >> Why is it compiling subproject unix ? > > This will have been set by the configure script. Did you set target > triple when you ran ./configure? > > David I found why I think : ifeq ($(GNUSTEP_TARGET_OS), mingw32) libgnustep-base_SUBPROJECTS+=win32 else libgnustep-base_SUBPROJECTS+=unix endif and since I am using mingw32ce it's not matched... ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cross compiling gnustep on embedded device (wince)
On 25 Sep 2009, at 17:06, Vincent R. wrote: On Fri, 25 Sep 2009 16:59:41 +0100, David Chisnall wrote: On 25 Sep 2009, at 16:57, Vincent R. wrote: Why is it compiling subproject unix ? This will have been set by the configure script. Did you set target triple when you ran ./configure? David I found why I think : ifeq ($(GNUSTEP_TARGET_OS), mingw32) libgnustep-base_SUBPROJECTS+=win32 else libgnustep-base_SUBPROJECTS+=unix endif and since I am using mingw32ce it's not matched... You can try just tweaking it to match on mingw32ce too, but I don't think anyone else has tested it on a Wince machine, so you may need to do some tweaking to make it work if you get any errors. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cross compiling gnustep on embedded device (wince)
Hi, I am trying to cross-compile gnustep-make and gnustep-base and I would have some questions and remarks/feedback in this area. My goal is to be able to do an hello world using objective C on window mobile device. My current issue is the fact makefiles are adding a reference to /usr/include and it makes some conflict with includes from my toolchains: vinc...@vincent-pc:~/projects/GNUstep/gnustep-base-1.19.1$ make messages=yes target=arm-mingw32ce This is gnustep-make 2.0.8. Type 'make print-gnustep-make-help' for help. Making all in Source... make[1]: entrant dans le répertoire « /home/vincent/projects/GNUstep/gnustep-base-1.19.1/Source » Making all in subprojects of library libgnustep-base... make[2]: entrant dans le répertoire « /home/vincent/projects/GNUstep/gnustep-base-1.19.1/Source/Additions » Making all for subproject Additions... arm-mingw32ce-gcc GSCategories.m -c \ -MMD -MP -Wall -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -DGNUSTEP_WITH_DLL -g -Wall -DDEBUG -fno-omit-frame-pointer -DGSWARN -DGSDIAGNOSE -Wno-import -g -fno-strict-aliasing -fgnu-runtime -I../../Headers/Additions -I../. -I../ -I../../Headers -I. -I/home/vincent/opt/mingw32ce-4.4.0/arm-mingw32ce/GNUstep/System/Library/Headers -I/home/vincent/opt/mingw32ce-4.4.0/arm-mingw32ce/GNUstep/Local/Library/Headers -I/home/vincent/opt/mingw32ce-4.4.0/arm-mingw32ce/lib/libffi-3.0.8/include -I/usr/include -I/home/vincent/GNUstep/Library/Headers -I/home/vincent/opt/mingw32ce-4.4.0/arm-mingw32ce/GNUstep/Local/Library/Headers -I/home/vincent/opt/mingw32ce-4.4.0/arm-mingw32ce/GNUstep/System/Library/Headers \ -o obj/GSCategories.m.o In file included from /home/vincent/opt/mingw32ce-4.4.0/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/include/windows.h:102, from ../../Headers/Additions/GNUstepBase/preface.h:51, from ../../Headers/Foundation/NSObjCRuntime.h:32, from ../../Headers/Foundation/NSObject.h:31, from ../../Headers/Foundation/FoundationErrors.h:29, from ../../Headers/Foundation/Foundation.h:33, from GSCategories.m:27: /home/vincent/opt/mingw32ce-4.4.0/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/include/winsock2.h:68: error: conflicting types for 'fd_set' /usr/include/sys/select.h:78: note: previous declaration of 'fd_set' was here When cross-compiling there shoudln't have -I/usr/include, in the worst case it could be $TOOLCHAIN_ROOT/usr/include with in my case TOOLCHAIN_ROOT=/home/vincent/opt/mingw32ce-4.4.0/arm-mingw32ce. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
