RE: Problems with Objc Runtime and Foundation Classes

[S.B., Vaitheeswaran]

If you have suggested this in the context of the single windows
installer that does all the installation then I am not sure how I can
make the change in "ffcall/trampoline/config.h" and then restart the
installation process. On the other hand I am trying to install
everything manually by following instructios in readme.mingwin once
again. I get stuck at this point, when installing ffcall, make install
fails like this:
"
$ make install
cd avcall; make install
make[1]: Entering directory `/home/vsb/GNUStep/ffcall-1.8d/avcall'
if [ ! -d C:/GNUstep/System ] ; then mkdir -p C:/GNUstep/System ; fi
if [ ! -d C:/GNUstep/System ] ; then mkdir -p C:/GNUstep/System ; fi
if [ ! -d C:/GNUstep/System/Libraries/ix86/mingw32 ] ; then mkdir -p
C:/GNUstep/System/Libraries/ix86/mingw32 ; fi
/bin/sh ./libtool --mode=install /bin/install -c -m 644 libavcall.la
C:/GNUstep/System/Libraries/ix86/mingw32/libavcall.la
libtool: install: `C:/GNUstep/System/Libraries/ix86/mingw32' must be an
absolute directory name
Try `libtool --help --mode=install' for more information.
make[1]: *** [install] Error 1
make[1]: Leaving directory `/home/vsb/GNUStep/ffcall-1.8d/avcall'
make: *** [install] Error 2
"

but if I just do the ./configure without any parameters then make
install succeeds but I get a problem while installing gnustep-base.
"
 Linking library libgnustep-base ...
gnustep-base.exp(.edata+0x574):fake: undefined reference to
`__objc_class_name_GSFFCallInvocation'
C:\msys\1.0\mingw\bin\dllwrap.exe: gcc exited with status 1
make[2]: *** [shared_obj/ix86/mingw32/gnu-gnu-gnu/gnustep-base.dll]
Error 1
make[1]: *** [libgnustep-base.all.library.variables] Error 2
make[1]: Leaving directory `/home/vsb/GNUStep/gnustep-base-1.6.0/Source'
make: *** [internal-all] Error 2
"

I've tried copying the ffcal libraries manually to
C:\GNUstep\System\Libraries\ix86\mingw, still doesn't compile. Any
pointers ?

Vaithee.


-----Original Message-----
From: Adam Fedor [mailto:fedor@doc.com]
Sent: Wednesday, June 18, 2003 10:25 AM
To: S.B., Vaitheeswaran
Cc: Tom Koelman; discuss-gnustep@gnu.org
Subject: Re: Problems with Objc Runtime and Foundation Classes


Maybe you could look in the config.log file to see why the malloc test 
failed:

Sources/ffcal/trampoline/config.log

If there's nothing obvious, perhaps force CODE_EXECUTABLE to be defined 
as 1 (ffcall/trampoline/config.h) and recompile ffcall. Be sure to also 
run 'make check' to see if it was really ok.


On Wednesday, June 18, 2003, at 11:05 AM, S.B., Vaitheeswaran wrote:

> So, whats the fix ? do u have the intaller software and installation
> scripts.
>
> Vaithee
>
> -----Original Message-----
> From: Tom Koelman [mailto:tkoelman@xs4all.nl]
> Sent: Wednesday, June 18, 2003 12:30 AM
> Cc: S.B., Vaitheeswaran; Adam Fedor
> Subject: Re: Problems with Objc Runtime and Foundation Classes
>
>
> The following message is a courtesy copy of an article
> that has been posted to gmane.comp.lib.gnustep.general as well.
>
> "S.B., Vaitheeswaran" <vaitheeswaran.s.b@attws.com> writes:
>
>> I am trying to use the windows intaller version of GNUStep and
getting
>> into trouble. Please find attached the file installer.tar.bz2 file to
>> this email and help me.
>
> Checking the logs, the first suspicious difference I find is
>
> checking whether code in malloc'ed memory is executable... yes
>
> which on my (Windows 2000) machines gives "no". I don't know what it
> means, though on your machine I think this should result in
> $cl_cv_codeexec being "yes" in the configure script and consequently
> CODE_EXECUTABLE set to 1 in confdefs.h. This would, I'd expect, result
> in a config.h containing #define CODE_EXECUTABLE 1 as well. Here I
> start getting confused, because on my system, where the
> malloc-mem-exec-test fails, config.h make CODE_EXECUTABLE 1. Hmm.
>
> The actual thing that goes wrong in your logs is compiling
> trampoline/trampoline.c in the ffcall project:
>
> trampoline.c:85: parse error before '?' token
>
> This the line containing two question marks in the following code
> block:
>
> #ifndef CODE_EXECUTABLE
>   /* How do we make the trampoline's code executable? */
>   #if defined(HAVE_MACH_VM) || defined(__convex__) ||
> defined(HAVE_WORKING_MPROTECT) || defined(HAVE_SYS_M88KBCS_H)
>   /* mprotect() [or equivalent] the malloc'ed area. */
>     #define EXECUTABLE_VIA_MPROTECT
>   #else
>     #ifdef HAVE_MMAP
>       /* Use an mmap'ed page. */
>       #define EXECUTABLE_VIA_MMAP
>       #ifdef HAVE_MMAP_ANONYMOUS
>         /* Use mmap with the MAP_ANONYMOUS or MAP_ANON flag. */
>         #define EXECUTABLE_VIA_MMAP_ANONYMOUS
>       #else
>         /* Use mmap on /dev/zero. */
>         #define EXECUTABLE_VIA_MMAP_DEVZERO
>       #endif
>     #else
>       #ifdef HAVE_SHM
>         /* Use an shmat'ed page. */
>         #define EXECUTABLE_VIA_SHM
>       #else
>       ??
>       #endif
>     #endif
>   #endif
> #endif
>
> This indicates that for some reason your CODE_EXECUTABLE is not
> defined, otherwise it would never get to line 85.
>
> So having executable malloc memory causes compiling ffcall to fail,
> which is a fatal error. Adam, do you know what the significance of
> this test is?
>
> Tom
>