Thanks Arni,<br><br>Created the issue<br><br>http://code.google.com/p/admb-project/issues/detail?id=59<br><br>Target for next Milestone3.<br><br>Johnoel<br><br>----- Original Message -----<br>From: Arni Magnusson <arnima@hafro.is><br>Date: Wednesday, April 22, 2009 6:40 am<br>Subject: Re: Broken tpl2cpp in Windows<br>To: Johnoel Ancheta <johnoel@hawaii.edu><br>Cc: users@admb-project.org<br><br>> I finally found the problem. The broken tpl2cpp in ADMB for <br>> MinGW gets <br>> created from the call:<br>> <br>>    gcc -I. -DUX mylex.c -otpl2cpp<br>> <br>> The -DUX should only be used when compiling mylex.c->tpl2cpp on <br>> Linux. In <br>> mylex.c, Dave Fournier defined a macro called UX that helps the <br>> compiler <br>> choose the right lines of code, depending on whether mylex.c is <br>> being <br>> compiled on Windows or Linux. By using -DUX it calls things <br>> appropriate <br>> for Linux, while bypassing the code intended for Windows. In <br>> other words, <br>> a healthy tpl2cpp for MinGW should be created with the call<br>> <br>>    gcc -I. mylex.c -otpl2cpp<br>> <br>> or better still<br>> <br>>    gcc -s mylex.c -o tpl2cpp<br>> <br>> for a leaner executable.<br>> <br>> ---<br>> <br>> The problem lies in mingw.mak, which currently calls <br>> optg32-rh8-laplace.mak. As the name implies, the latter makefile <br>> is <br>> intended for Red Hat 8 Linux and is therefore not appropriate <br>> for making <br>> ADMB for Windows.<br>> <br>> The solution is to edit mingw.mak so that it calls a makefile <br>> intended for <br>> making ADMB for Windows. This is a much better solution than <br>> making ADMB <br>> for Windows dependent on cat.exe. Dave Fournier already did the <br>> hard work <br>> creating the UX macro to make ADMB for Windows self-contained.<br>> <br>> The same corrections need to be made for tpl2rem, which also <br>> uses Red Hat <br>> 8 Linux makefiles. It looks like the Windows makefiles will be <br>> very <br>> similar, except no -DUX.<br>> <br>> Quack,<br>> <br>> Arni