Powder Toy on the iPod touch?

  • Aizria
    30th Jul 2010 Member 0 Permalink
    Felix

    If I remove that line from it, I need mw_stdarg.h (or so it seems) which, for some reason, I can't find.

    plypencil

    I'm wary of doing that as stdarg.h not working is currently breaking quite a few things that I'm not sure would be wise to patch, and that I'm not sure how to patch. I don't really know to what extent it is used in PT, but it's definitely used as the full 1.5kb text file of errors that I'm stuck on currently seems to stem entirely from stdarg.h not working.
  • plypencil
    30th Jul 2010 Member 0 Permalink
    Its basically used as a shortcut tool, instead of typing

    command(arg1,arg2)
    command(arg3)

    That module allows you to

    command(arg1,arg2,arg3)

    Well thats how I understand it
  • Aizria
    30th Jul 2010 Member 0 Permalink
    Well, I just looked up the stdarg.h source using Google and found this:

    /*
    * stdarg.h
    *
    * Provides facilities for stepping through a list of function arguments of
    * an unknown number and type.
    *
    * NOTE: Gcc should provide stdarg.h, and I believe their version will work
    * with crtdll. If necessary I think you can replace this with the GCC
    * stdarg.h (or is it vararg.h).
    *
    * Note that the type used in va_arg is supposed to match the actual type
    * *after default promotions*. Thus, va_arg (..., short) is not valid.
    *
    * This file is part of the Mingw32 package.
    *
    * Contributors:
    * Created by Colin Peters <colin@bird.fu.is.saga-u.ac.jp>
    *
    * THIS SOFTWARE IS NOT COPYRIGHTED
    *
    * This source code is offered for use in the public domain. You may
    * use, modify or distribute it freely.
    *
    * This code is distributed in the hope that it will be useful but
    * WITHOUT ANY WARRANTY. ALL WARRANTIES, EXPRESS OR IMPLIED ARE HEREBY
    * DISCLAMED. This includes but is not limited to warranties of
    * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    *
    * $Revision: 1.1.1.1 $
    * $Author: brandon6684 $
    * $Date: 2001/12/18 22:53:51 $
    *
    */
    /* Appropriated for Reactos Crtdll by Ariadne */

    #ifndef _STDARG_H_
    #define _STDARG_H_

    /*
    * Don't do any of this stuff for the resource compiler.
    */
    #ifndef RC_INVOKED

    /*
    * I was told that Win NT likes this.
    */
    #ifndef _VA_LIST_DEFINED
    #define _VA_LIST_DEFINED
    #endif

    #ifndef _VA_LIST
    #define _VA_LIST
    typedef char* va_list;
    #endif


    /*
    * Amount of space required in an argument list (ie. the stack) for an
    * argument of type t.
    */
    #define __va_argsiz(t) \
    (((sizeof(t) + sizeof(int) - 1) / sizeof(int)) * sizeof(int))


    /*
    * Start variable argument list processing by setting AP to point to the
    * argument after pN.
    */
    #ifdef __GNUC__
    /*
    * In GNU the stack is not necessarily arranged very neatly in order to
    * pack shorts and such into a smaller argument list. Fortunately a
    * neatly arranged version is available through the use of __builtin_next_arg.
    */
    #define va_start(ap, pN) \
    ((ap) = ((va_list) __builtin_next_arg(pN)))
    #else
    /*
    * For a simple minded compiler this should work (it works in GNU too for
    * vararg lists that don't follow shorts and such).
    */
    #define va_start(ap, pN) \
    ((ap) = ((va_list) (&pN) + __va_argsiz(pN)))
    #endif


    /*
    * End processing of variable argument list. In this case we do nothing.
    */
    #define va_end(ap) ((void)0)


    /*
    * Increment ap to the next argument in the list while returing a
    * pointer to what ap pointed to first, which is of type t.
    *
    * We cast to void* and then to t* because this avoids a warning about
    * increasing the alignment requirement.
    */

    #define va_arg(ap, t) \
    (((ap) = (ap) + __va_argsiz(t)), \
    *((t*) (void*) ((ap) - __va_argsiz(t))))

    #endif /* Not RC_INVOKED */

    #endif /* not _STDARG_H_ */

    Compare that to the source that I posted previously as having for stdarg.h! Is it just me, or does somthing smell more than a little fishy?
  • plypencil
    30th Jul 2010 Member 0 Permalink
    Tastes quite fishy too!
  • Aizria
    30th Jul 2010 Member 0 Permalink
    Aha! I found, on my iPod, the stdarg.h that gcc supplies and took a gander at it's source. It looks far more valid than the one I ended up with through other means. I may use gcc's stdarg.h instead of the one I've been trying to use. That should hopefully fix my problems. Mabey, just mabey.
  • kamikai
    30th Jul 2010 Member 0 Permalink
    c'mon ESS, you can do it!
    At least Lolzy and i are pumped for it, and i think many other people who are on the forum will like it to, not to mention all of the random app browsing people...
  • Aizria
    30th Jul 2010 Member 0 Permalink
    Now 38.0 gives a much shorter readout:

    gcc -DINTERNAL -opowder -Wall -std=c99 -D_POSIX_C_SOURCE=200112L -fgnu89-inline  -O3 -ffast-math -ftree-vectorize -funsafe-math-optimizations -lSDL -lm -lbz2  Â powder.c http.c md5.c update.c -DLIN64
    powder.c:14777: error: expected identifier or '(' before string constant
    powder.c: In function 'SDL_main':
    powder.c:15847: warning: comparison is always true due to limited range of  data type
    update.c: In function 'exe_name':
    update.c:60: warning: implicit declaration of function 'malloc'
    update.c:60: warning: incompatible implicit declaration of built-in function  'malloc'
    update.c:67: warning: implicit declaration of function 'realloc'
    update.c:67: warning: assignment makes pointer from integer without a cast
    update.c:72: warning: implicit declaration of function 'free'
    update.c: In function 'update_start':
    update.c:118: warning: incompatible implicit declaration of built-in function  'malloc'
    make: *** [powder] Error 1

    I can't seem to get 39.0 to run all the way to completion though. For some reason it's now taking an inordinate amount of time. Any thoughts on the readout above?
  • Aizria
    30th Jul 2010 Member 0 Permalink
    Every time I try to compile 39.0, even though it takes a long time, if I try to let it just run it's course, mobile terminal crashes every time. Though this is running the make command via a Python script. Mabey if I do it without the script I can get a better idea of what's going on and it might not crash, hang on a sec...

    EDIT: There! I did the make outside of the script and it ran without crashing! It has a similar error output as 38.0. Hang on a sec and I'll post the readout here.

    Grr! I can't get it output to a text file! I even tried "make > /var/mobile/Logs/makeLog39.0.txt 2>&1" outside of the script and mobile terminal still crashes for some reason. It seems to have a problem with outputting it to a text file for some reason. Oh well. Just know that it's approximately the same readout as 38.0. I'll scan the readout for any differences and post those here.
  • Aizria
    30th Jul 2010 Member 0 Permalink
    Oops! I should have checked the log file before saying that it didn't write out! It appears that the afforementioned command managed to do it before mobile terminal crashed! Here's the log file's contents:

    gcc -DINTERNAL -opowder -Wall -std=c99 -D_POSIX_C_SOURCE=200112L -fgnu89-inline  -O3 -ffast-math -ftree-vectorize -funsafe-math-optimizations -lSDL -lm -lbz2ï ¿½ �� �  powder.c http.c md5.c update.c -DLIN64
    powder.c: In function 'SDL_main':
    powder.c:8039: warning: comparison is always true due to limited range of  data type
    powder.c: At top level:
    icon.h:22: warning: 'app_icon_w32' defined but not used
    update.c: In function 'exe_name':
    update.c:60: warning: implicit declaration of function 'malloc'
    update.c:60: warning: incompatible implicit declaration of built-in function  'malloc'
    update.c:67: warning: implicit declaration of function 'realloc'
    update.c:67: warning: assignment makes pointer from integer without a cast
    update.c:72: warning: implicit declaration of function 'free'
    update.c: In function 'update_start':
    update.c:118: warning: incompatible implicit declaration of built-in functionï ¿½ �� �'malloc'
    ld: unknown option: -opowder
    collect2: ld returned 1 exit status
    make: *** [powder] Error 1

    As before, I invite anyone with thoughts about the errors that I'm getting for either 39.0, posted here, or 38.0, a post above, to put in their two-cents.
  • plypencil
    30th Jul 2010 Member 0 Permalink
    I only see warnings there no errors? (Sorry its early for me lol, can someone point it out?)