I am afraid that I have found yet another bug. It's in the version 1.8.0c, compiled with MinGW, under WinXP (those things probably don't matter, but I provided them just in case). The bug is an abnormal program exit occuring when the parsing (building) is taking place. After some tests I managed to pin down the problem: the crash happens when there is an unknown function somewhere in the code AND that function has a constant string as one of its parameters. I first triggered it by typing 'pile->setehaviour(ON_PICK, "pickUp")' instead of 'setBehaviour'. I tried to pin down the problem with GDB, but I've got nothing. It wasn't a segfault. The GDB just said "Program exited with code 03". No backtrace or whatsoever available, because the program is done running when this message appears. However, I think you will find useful the information that the string "function 'xxx' not found" is sent to the outstream. I tried making an error in the line next to the bug-trigerring one to check if it reaches that. It doesn't. I hope that you find that bug report helpful and will use it to make your library even better. If you won't be able to reproduce the bug (I managed to reproduce it with 3 different pieces of code, so its unlikely), I can send you the code that suffered from this bug. [EDIT] I've just had a thought... it could also be an error in the standard "bstr" package. But it's rather unlikely, when there is no errors in the code the strings allocate properly and everything works like a charm. [/EDIT] Yours, Jakub.

I would have to add bstr support (or some string support) to the framework and do some other things... I'm at work now, so I'm unable to do this ;). But I can give you the smallest amount of code that causes the error, here. I hope I'm not too annoying ;)

I use a slightly altered "linux_alt1" file: here. You have to make the directory "lib" under the lib root by hand though.

[EDIT] But I am pretty sure that you could compile the code I provided under any standard compliant compiler, so there's no need for MinGW. But well, having GNU for Windows won't hurt you. Oh, and if you want to use makefiles with MinGW, you need to download this:
MingW32-Make
because the make that comes with the standard package is no good. [/EDIT]

Here's your adjusted makefile:

CXX = g++CXXFLAGS =BIN = ../../bin/testframe.exeOBJS = bstr.o main.o test_build.o all: $(BIN)bstr.o: main.o: test_build.o: $(BIN): $(OBJS)	$(CXX) $(CXXFLAGS) $(OBJS) -o $(BIN) -langelscriptclean:	rm -f *.o *~ $(BIN)	.PHONY: clean

Some things I changed and why:
1. CXX should be g++. g++ is the C++ compiler, gcc is the C compiler. You can tell gcc to compile c++ code, but it's not worth the effort.
2. Don't link directly with the .a, use the -l switch together with the name of your libfile. For you, it'll be "-langelscript". For this, you have to copy your .a file to the "mingw/lib/" directory or specify an additional library directory with the "-L" switch.
3. You don't have to specify that the object depends on its own source code (the parts you had after the colons). And you don't have to tell make to use CXX for the .cpp files, as long as you set the cxx variable. [EDIT]Haven't seen the project, but you probably need to add some headers to the dependency lists. I'm pretty sure your main.cpp depends on both bstr.h and test_build.h, right?[/EDIT]
4. It's possible to use ld directly, but most of the time you use g++ for linking also. That's because the g++ (and gcc) compiler does the linking by default. To tell it NOT to do the linking of an executable, you need to specify -c.

Whew, that's all. Look at me, I'm teaching the almighty library developer :P. But seriously, you should read some tut on makefile's and gnu compilers to quickly get the hang of it.

How nice of you :). Know what, you've got better and faster support than some of the commercial libs and programs have.

I'm feeling like contributing something to your library now (for your dedication and time and so on ;). Maybe you would be interested in having a dedicated MinGW makefile, with standard interface. Standard interface, meaning that typing:

make
make install

Does all the job. "make" creates the lib, and "make install" copies the library and include files to respective directiores under MinGW. Just tell me if you want that makefile and I'll provide it in no-time ;). (Oh, and also, remember to include the empty "lib" directory in the next distribution of your library, so that all those different makes don't choke on it. And put a "delete.me" or something file in it, so it won't get lost when unarchiving, some unarchivers ommit empty dirs).