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'll check into it. Thanks for letting me know.

If possible, could you write a small test case for the testframework that reproduces the bug? That would make it easier for me to find the error.

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 ;)

Don't worry. You're only helping making the library better.

I'm not very used to using mingw. I have installed it and msys. When I try to run make on one of the linux make files it gives me an error. Could you send me the makefile you use for building the library and let me know how to compile it with mingw?

I'll try to figure it out myself, but if you could just tell me it would be easier and faster. :)

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]

I tried to reproduce the problem using MSVC but couldn't so I'm thinking it only shows up on MinGW (and similar compiler).

OK, so I did manage to compile the library with MinGW. Now I'm trying to compile the testframework. But I haven't figured out how to do the linking. Any hints?

I have 3 object files and the angelscript library.

CPP = gccCCFLAGS =BIN = ../../bin/testframe.exebstr.o: ../../source/bstr.cpp	$(CPP) -c ../../source/bstr.cpp -o bstr.o $(CXXFLAGS)main.o: ../../source/main.cpp	$(CPP) -c ../../source/main.cpp -o main.o $(CXXFLAGS)test_build.o: ../../source/test_build.cpp	$(CPP) -c ../../source/test_build.cpp -o test_build.o $(CXXFLAGS)OBJS = bstr.o        main.o        test_build.o all: $(BIN)$(BIN): $(OBJS)	ld -dn -o $(BIN) $(OBJS) ../../lib/libangelscript.a.cpp.o:	$(CPP) $(CCFLAGS) -c $< -o $@clean:	rm -f *.o *~ $(BIN)

When linking there are a lot of missing functions (_mainCRTStartUp, memcpy, etc). I think I need to link with the default libraries, but I'm not yet sure how. Can you show me?

I should learn to use MinGW, because it will allow me check portability issues on at least two compilers.

Regards,
Andreas

I figured it out already. Reading the manual gives a suprising amount of useful information ;)

I link the program with

g++ -o $(BIN) $(OBJS) ../../lib/libangelscript.a

I also found the problem. It is an assertion error that makes the program bail out. Somewhere a temporary variable isn't correctly cleaned up when the function name isn't found. I'll find the bug as soon as possible.

I didn't find the problem on MSVC because I forgot that I using the release version of the library ;)

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.

Thanks, for the explanations. I prefer knowing why I should do what I should do. Now I can build a nice makefile for the test framework that I can release together

I found the bug-fix for you:

The assert() in asCCompiler::CompileStatementBlock() should only be done if there is no compiler errors. So change line 349 in as_compiler.cpp to:

if( !hasCompileErrors )	assert(tempVariables.GetLength() == 0);

Thanks for the help.

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).