[dizzy]

Only Makefile.am's files (the one from basedir and the one from "compat" if you intend to include that too), configure.ac and autogen.sh to make regeneration fast. However, I can help out updating them if you are doing the compat stuff differently.

[Kazan]

[dizzy]

Hey, now that's cool! Anyways, you seem to have managed to get it working fine, here it crashed when trying to load some pof file (might be I was loading a bad pof or that I use Linux/AMD64). Or maybe you have made some other changes too to the codes

[taylor]

And how about getting it in CVS so that we can all play!!

[Kazan]

i cvs committed everything but the autotools

i am having to **** with the configure.ac because i'm having problems with the detection of DevIL

[dizzy]

If I remember well, to detect the three DevIL libraries I just check for their init functions in each of them. The check tries to compile a program by declaring that function and linking it to the libs (AC_CHECK_LIB) to see if it links and if it does it should add it to LIBS variable replaced into Makefile.in's. What's the problem, maybe we can help

[Kazan]

false negatives

[dizzy]

I can make configure.ac bail out on negatives (it should anyways if you think of it, you require DevIL to be present) and then it should be easy to check it out what exactly fails in config.log.

Basically if your lib is installed in a directory listed in /etc/ld.so.conf (like /usr/lib, /usr/local/lib, etc) then try to rerun "ldconfig" to rebuild the ld.so.cache if you have installed DevIL recently. If you installed DevIL libs into another, exotic directory "export LD_LIBRARY_PATH" variable to point to that place before running configure... But in any case, checking out "config.log" should show exactly what fails on the test program that configure tries to compile and link to test for the library presence.

[Kazan]

if was failing out on negatives - it was falsely reporting negatives - simply hacking the finished makefile and adding -lIL -lILU -lILUT links and /etc/ld.so.conf is configured recorrect.

and thanks for the info on config.log - i'll restore the origional macros and check

and WTFH is with strcpy() not working? i had to replace all calls to strcpy() with strncpy()!

i have other bugs of this unexplained nature that i've never encountered on linux before

[dizzy]

Oh, I have no idea with strcpy(). I don't remember touching anything about strcpy(), only strncmp()/strncasecmp(). You get errors when compiling about strcpy() ? Or when linking ?

I didnt got any errors about that, very strange

But by rereading your message my guess is that you are speaking of runtime behaivour bugs, strange. Make sure you are not using strcpy() when source and destination overlap (is the equivalent of memcpy() with the same limitations). If they do overlap you whould have to use memmove() instead (of course, with length precalculation). For debugging memory problems under Linux I also recommend valgrind, www.valgrind.org. Is an easy to install/use memory debugging tool that acts like a CPU emulator, it catches all read/write operations and at the library level (all new/delete operations) and so on. If for example you have problems like using strcpy() on overlapping strings he will tell you so (that's how I found out about such a "strange" bug I was having with strcpy() some time ago...). Or maybe you should consider using std::string instead of C-strings and their operations if you are not time critical

After installing valgrind just use something like this to start your program:
$ valgrind --tool=memcheck --num-callers=10 ./pcs2

"valgrind" might not be very useful if you get hundred of errors from it (not because it might be a valgrind bug but still it's not useful when that happens).

[Kazan]

run time errors - it simply would not perform it's function

src and dst do not overlap - i was using strcpy inside my custom C++ string class (cannot debug into std::string and std::vector on windows.. gives you garbage)