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.
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
/* * 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. */
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.
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...
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?
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.
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:
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.