Crosscompiling gnustep
Hi, I am trying to crosscompile GNUstep on Linux to Windows. I did: $ export CC=/home/stevko/Developer/mingw/bin/i586-mingw32-gcc $ cd core/make $ ./configure --host=i586-mingw32 --prefix=/home/stevko/Developer/Windows/GNUstep $ make install $ cd ../base $ ./configure --host=i586-mingw32 --prefix=/home/stevko/Developer/Windows/GNUstep And I got: checking whether setpgrp takes no argument... configure: error: cannot check setpgrp when cross compiling How can I fix that? Besides that, I expect GNUstep make to want me to run GNUstep.sh later during compilation. However, what GNUstep.sh I should run? The one I have just installed? But if that script calls some binary executables, they will not work on my system. Thanks for any hints, Stefan Urbanek -- http://stefan.agentfarms.net First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Crosscompiling gnustep
Excuse me for replying to myself ... I moved a bit forward and i am gettin different errors (see below) ... On Tue, 2005-04-26 at 20:19 +0200, Stefan Urbanek wrote: > Hi, > > I am trying to crosscompile GNUstep on Linux to Windows. > > I did: > > $ export CC=/home/stevko/Developer/mingw/bin/i586-mingw32-gcc > $ cd core/make > $ ./configure --host=i586-mingw32 > --prefix=/home/stevko/Developer/Windows/GNUstep > $ make install > $ cd ../base > $ ./configure --host=i586-mingw32 > --prefix=/home/stevko/Developer/Windows/GNUstep > > And I got: > > checking whether setpgrp takes no argument... configure: error: cannot > check setpgrp when cross compiling > > How can I fix that? > I have removed some lines from configure.ac regardless of future impacts: -AC_CHECK_FUNCS(killpg setpgrp setpgid) +AC_CHECK_FUNCS(killpg) -AC_FUNC_SETPGRP +# AC_FUNC_SETPGRP then i run into ffcall/libffi problem. I have installed the ffcall: $ ./configure --prefix=/home/stevko/Developer/Windows/ --host=i586-mingw32 --enable-shared $ make $ make install Then I did: [EMAIL PROTECTED] base]$ ./configure --host=i586-mingw32 --prefix=/home/stevko/Developer/Windows/GNUstep --enable-ffcall --with-ffi-include=/home/stevko/Developer/Windows/include/ --with-ffi-library=/home/stevko/Developer/Windows/lib/ And I still get: ... checking callback.h usability... yes checking callback.h presence... yes checking for callback.h... yes checking "for forwarding callback in runtime"... yes checking "FFI library usage"... none You do not have either ffcall or libffi installed, or configure needs --with-ffi-include and/or --with-ffi-library flags so GNUstep can find them GNUstep requires ffcall or libffi and proper libobjc hooks to do invocations and DO. (This does not apply on apple-apple-apple systems where DO is not compatible with other GNUstep systems.) You most likely do not want to build base without DO support. Many things, including all applications, won't work at all without DO. If you really want to build -base without DO support, add --disable-do to the configure arguments. For more information, read the GNUstep build guide, ffcall section: http://documents.made-it.com/GNUstep/buildguide.html#FOREIGN.FUNCTION.INTERFACESconfigure: error: Incomplete support for ffi functionality. Thanks for any hints, Stefan Urbanek p.s.: I have created the mingw cross-compilation environment as described here: http://www.mingw.org/MinGWiki/index.php/build%20a%20Win32%20x-compiler% 20for%20Linux -- http://stefan.agentfarms.net First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Crosscompiling gnustep
On Apr 26, 2005, at 1:11 PM, Stefan Urbanek wrote: ... checking callback.h usability... yes checking callback.h presence... yes checking for callback.h... yes checking "for forwarding callback in runtime"... yes checking "FFI library usage"... none You do not have either ffcall or libffi installed, or configure needs --with-ffi-include and/or --with-ffi-library flags so GNUstep can find them GNUstep requires ffcall or libffi and proper libobjc hooks to do invocations and DO. (This does not apply on apple-apple-apple systems where DO is not compatible with other GNUstep systems.) Well, the config.log file would help here. It's just trying to see if the ffcall libraries link correctly, which should work when cross-compiling. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Crosscompiling gnustep
On Tue, 2005-04-26 at 14:24 -0600, Adam Fedor wrote: > On Apr 26, 2005, at 1:11 PM, Stefan Urbanek wrote: > > > > ... > > checking callback.h usability... yes > > checking callback.h presence... yes > > checking for callback.h... yes > > checking "for forwarding callback in runtime"... yes > > checking "FFI library usage"... none > > > > You do not have either ffcall or libffi installed, or configure needs > > --with-ffi-include and/or --with-ffi-library flags so GNUstep can find > > them > > GNUstep requires ffcall or libffi and proper libobjc hooks to do > > invocations and DO. > > (This does not apply on apple-apple-apple systems where DO is > > not compatible with other GNUstep systems.) > > > > Well, the config.log file would help here. It's just trying to see if > the ffcall libraries link correctly, which should work when > cross-compiling. > http://stefan.agentfarms.net/Download/GNUstep/Trash/config.log ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Crosscompiling gnustep
On Apr 26, 2005, at 1:11 PM, Stefan Urbanek wrote: I have removed some lines from configure.ac regardless of future impacts: -AC_CHECK_FUNCS(killpg setpgrp setpgid) +AC_CHECK_FUNCS(killpg) -AC_FUNC_SETPGRP +# AC_FUNC_SETPGRP I think it's just the AC_FUNC_SETPGRP that is the problem, and we'd just have to enclose that in a check for cross compiling... if test "x$target" = "x$host"; then ... fi ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Crosscompiling gnustep
On Apr 26, 2005, at 2:28 PM, Stefan Urbanek wrote: On Tue, 2005-04-26 at 14:24 -0600, Adam Fedor wrote: On Apr 26, 2005, at 1:11 PM, Stefan Urbanek wrote: ... checking callback.h usability... yes checking callback.h presence... yes checking for callback.h... yes checking "for forwarding callback in runtime"... yes checking "FFI library usage"... none Well, the config.log file would help here. It's just trying to see if the ffcall libraries link correctly, which should work when cross-compiling. http://stefan.agentfarms.net/Download/GNUstep/Trash/config.log Well here's the error message. Did ffcall really get installed correctly? /home/stevko/Developer/Windows/lib//libcallback.a: could not read symbols: Archive has no index; run ranlib to add one ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Crosscompiling gnustep
On Tue, 2005-04-26 at 14:40 -0600, Adam Fedor wrote: > On Apr 26, 2005, at 2:28 PM, Stefan Urbanek wrote: > > > On Tue, 2005-04-26 at 14:24 -0600, Adam Fedor wrote: > >> On Apr 26, 2005, at 1:11 PM, Stefan Urbanek wrote: > >>> > >>> ... > >>> checking callback.h usability... yes > >>> checking callback.h presence... yes > >>> checking for callback.h... yes > >>> checking "for forwarding callback in runtime"... yes > >>> checking "FFI library usage"... none > >>> > >> > >> Well, the config.log file would help here. It's just trying to see if > >> the ffcall libraries link correctly, which should work when > >> cross-compiling. > >> > > > > http://stefan.agentfarms.net/Download/GNUstep/Trash/config.log > > > > > > Well here's the error message. Did ffcall really get installed > correctly? > > /home/stevko/Developer/Windows/lib//libcallback.a: could not read > symbols: Archive has no index; run ranlib to add one > I run ranlib manually. From ffcall installation output I see: ... /usr/bin/install -c -m 644 .libs/libcallback.a /home/stevko/Developer/Windows//lib/libcallback.a ranlib /home/stevko/Developer/Windows//lib/libcallback.a chmod 644 /home/stevko/Developer/Windows//lib/libcallback.a ... the ranlib line should read: i586-mingw32-ranlib /home/stevko/Developer/Windows//lib/libcallback.a Looks like misconfiguration of ffcall or a bug there. Then I used this configure command with --includedir and --libdir added: [EMAIL PROTECTED] base]$ ./configure --host=i586-mingw32 --prefix=/home/stevko/Developer/Windows/GNUstep --enable-ffcall --with-ffi-include=/home/stevko/Developer/Windows/include/ --with-ffi-library=/home/stevko/Developer/Windows/lib/ --includedir=/home/stevko/Developer/mingw/include/ --libdir=/home/stevko/Developer/mingw/lib I ended with: Compiling file NSPathUtilities.m ... NSPathUtilities.m: In function `NSHomeDirectoryForUser': NSPathUtilities.m:789: warning: implicit declaration of function `getpwnam' NSPathUtilities.m:789: warning: assignment makes pointer from integer without a cast NSPathUtilities.m:790: error: dereferencing pointer to incomplete type NSPathUtilities.m:792: error: dereferencing pointer to incomplete type make[2]: *** [shared_obj/NSPathUtilities.o] Error 1 make[1]: *** [libgnustep-base.all.library.variables] Error 2 make[1]: Leaving directory `/home/stevko/Developer/Sources/gnustep/core/base/Source' make: *** [internal-all] Error 2 It is too late now, i have to go to sleep. If anyone has any hints what should be done and what should do as next steps, let me know. I am also interested in the GNUstep.sh problem mentioned before. Regards, Stefan ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Crosscompiling gnustep
On Apr 26, 2005, at 12:19 PM, Stefan Urbanek wrote: Besides that, I expect GNUstep make to want me to run GNUstep.sh later during compilation. However, what GNUstep.sh I should run? The one I have just installed? But if that script calls some binary executables, they will not work on my system. Er, well you should run the GNUstep.sh you just installed to set up the build environment right. But you are right - there are some binary executables that will run user_home should just not run when we are cross compiling. The more problematic one is which_lib, which should really be compiled to run locally I guess... I think we used to have which_lib written as a perl script to deal with this problem before, but that was removed long ago, probably because no one every really used cross compiling... ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Crosscompiling gnustep
On Tue, 26 Apr 2005, Stefan Urbanek wrote:
I ended with:
Compiling file NSPathUtilities.m ...
NSPathUtilities.m: In function `NSHomeDirectoryForUser':
NSPathUtilities.m:789: warning: implicit declaration of function
`getpwnam'
NSPathUtilities.m:789: warning: assignment makes pointer from integer
without a cast
NSPathUtilities.m:790: error: dereferencing pointer to incomplete type
NSPathUtilities.m:792: error: dereferencing pointer to incomplete type
make[2]: *** [shared_obj/NSPathUtilities.o] Error 1
make[1]: *** [libgnustep-base.all.library.variables] Error 2
make[1]: Leaving directory
`/home/stevko/Developer/Sources/gnustep/core/base/Source'
make: *** [internal-all] Error 2
From your config.log:
configure:8379: checking pwd.h usability
configure:8391: /home/stevko/Developer/mingw/bin/i586-mingw32-gcc -c -g
-O2 -I/System/Library/Headers conftest.c >&5
conftest.c:68:17: pwd.h: No such file or directory
so mingw might not have getpwnam, but the code in NSPathUtilities.m reads:
#ifdef HAVE_PWD_H
#include // for getpwnam()
#endif
[...]
#if !defined(__MINGW__)
struct passwd *pw;
[gnustep_global_lock lock];
pw = getpwnam ([loginName cString]);
if (pw != 0 && pw->pw_dir != NULL)
{
s = [NSString stringWithCString: pw->pw_dir];
}
[gnustep_global_lock unlock];
#else
s = Win32GetUserProfileDirectory(loginName);
#endif
so it should not try to compile the part calling getpwnam. Is __MINGW__
defined under your crosscompiling environment? Maybe the line
#if !defined(__MINGW__)
could be changed to
#ifdef HAVE_PWD_H
not quite correct, but might work. Maybe others have a better idea.
Regards,
BALATON Zoltan
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Crosscompiling gnustep
Adam Fedor wrote: On Apr 26, 2005, at 12:19 PM, Stefan Urbanek wrote: Besides that, I expect GNUstep make to want me to run GNUstep.sh later during compilation. However, what GNUstep.sh I should run? The one I have just installed? But if that script calls some binary executables, they will not work on my system. Er, well you should run the GNUstep.sh you just installed to set up the build environment right. But you are right - there are some binary executables that will run Only one: user_home. Host native version will work fine. Just make sure you don't have a ~/GNUstep.sh to confuse things. One way to ensure things are clean is to do your cross-compiling as a specific user with the environment set up for it. user_home should just not run when we are cross compiling. The more problematic one is which_lib, which should really be compiled to run locally I guess... I think we used to have which_lib written as a perl script to deal with this problem before, but that was removed long ago, probably because no one every really used cross compiling... user_home and which_lib should work fine by using the host native versions. Just move the target versions away and copy in the host ones. Neither do very target or host specific things at the moment. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Crosscompiling gnustep
Stefan Urbanek wrote: On Tue, 2005-04-26 at 14:40 -0600, Adam Fedor wrote: On Apr 26, 2005, at 2:28 PM, Stefan Urbanek wrote: On Tue, 2005-04-26 at 14:24 -0600, Adam Fedor wrote: On Apr 26, 2005, at 1:11 PM, Stefan Urbanek wrote: ... checking callback.h usability... yes checking callback.h presence... yes checking for callback.h... yes checking "for forwarding callback in runtime"... yes checking "FFI library usage"... none Well, the config.log file would help here. It's just trying to see if the ffcall libraries link correctly, which should work when cross-compiling. http://stefan.agentfarms.net/Download/GNUstep/Trash/config.log Well here's the error message. Did ffcall really get installed correctly? /home/stevko/Developer/Windows/lib//libcallback.a: could not read symbols: Archive has no index; run ranlib to add one I run ranlib manually. From ffcall installation output I see: ... /usr/bin/install -c -m 644 .libs/libcallback.a /home/stevko/Developer/Windows//lib/libcallback.a ranlib /home/stevko/Developer/Windows//lib/libcallback.a chmod 644 /home/stevko/Developer/Windows//lib/libcallback.a ... the ranlib line should read: i586-mingw32-ranlib /home/stevko/Developer/Windows//lib/libcallback.a Looks like misconfiguration of ffcall or a bug there. Then I used this configure command with --includedir and --libdir added: [EMAIL PROTECTED] base]$ ./configure --host=i586-mingw32 --prefix=/home/stevko/Developer/Windows/GNUstep --enable-ffcall --with-ffi-include=/home/stevko/Developer/Windows/include/ --with-ffi-library=/home/stevko/Developer/Windows/lib/ --includedir=/home/stevko/Developer/mingw/include/ --libdir=/home/stevko/Developer/mingw/lib I ended with: Compiling file NSPathUtilities.m ... NSPathUtilities.m: In function `NSHomeDirectoryForUser': NSPathUtilities.m:789: warning: implicit declaration of function `getpwnam' NSPathUtilities.m:789: warning: assignment makes pointer from integer without a cast NSPathUtilities.m:790: error: dereferencing pointer to incomplete type NSPathUtilities.m:792: error: dereferencing pointer to incomplete type make[2]: *** [shared_obj/NSPathUtilities.o] Error 1 make[1]: *** [libgnustep-base.all.library.variables] Error 2 make[1]: Leaving directory `/home/stevko/Developer/Sources/gnustep/core/base/Source' make: *** [internal-all] Error 2 It is too late now, i have to go to sleep. If anyone has any hints what should be done and what should do as next steps, let me know. I am also interested in the GNUstep.sh problem mentioned before. For GNUstep.sh see other post. Problem here is __MINGW__ doesn't seem to be defined. It should be in Headers/Additions/GNUstepBase/preface.h If you're cross-compiling for windows getting that definition happening is pretty vital! Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
