Re: Tuxscreen build - malloc problem

Hi Matthew -
         In the configure script, if I change line 10440 - after it tests 
"cross_compiling" - to

   ac_cv_func_malloc_0_nonnull=yes       // instead of no

Then it works. Of course, I should probably add in the WARNING that comes 
out when it checks for forking earlier.... That is left as an exercise for 
the script_kiddies :-) This is definitely cheap&dirty!

BTW - I do have 0.5rc1 working on my Tuxscreen - without libpng it's sort 
of boring. The little dock thingies really are pretty tiny on a 640x480 
screen that's only 16x12 cm. Other than that, rxvt is my only X-app so far, 
and I haven't even figured out how to switch between the two copies! (It's 
probably in your docs which I need to reread.) It uses TinyX, and I don't 
know how complete it is for fonts and such. This is really my big 
opportunity to learn _all_about_X_ !

Thanks -
         Phil Olynyk

At 07:20 PM 09-04-03, you wrote:
>on Wed, Apr 09, 2003 at 07:07:36PM -0400, Phil Olynyk wrote:
> > Hi Matthew -
> >         I see that another cross-compiler guy is having trouble with
> > malloc. Here is my config.log for you to look at.
>
>Cool, many thanks.
>
> > BTW, I am cross-compiling.
> >         I just looked at the configure script. It looks like either it
> > didn't do the right thing with the cross-compile flag, (is that 
> something I
> > have to set in the options to configure?) or somewhere I should "set" the
> > $(ac_cv_func_malloc_0_nonnull+set) variable. It's fairly obvious that we
> > can't test the target platform implementation by using the host, after 
> all.
> > So probably I have to do something to tell configure that I know my target
> > malloc does exist, -- also all the other features it tries to test by
> > compile&execute!
>
>yeah, configure should at least 'know' its cross compiling and handle
>an tests that require execution accordingly - Im not sure why this is
>not happening.
>
>One cleanish workaround is to use a config.cache file with the malloc
>test result already defined - this is what the open zuarus guys do
>when this problem occurs.
>
> >         For me, editing the config.h file was a handy work-around.
>
>yeah, maybe a rather brutal fix is to redef this out in the source. I
>sure a cleaner solution must exist - is you come up with anything
>please let me know - or know an autogubbins based package that doesn't
>suffer this problem when x-compiled, I can then take a look at how
>thats avoiding it.
>
>Many thanks;
>
>   -- Matthew
>
>btw, do you have 0.5xx now running on the tux ?

OBT Software Corp.
"For a more reliable product sooner."