Hey,
I have a Problem with the Testing of an "Testing makeobj".
I get an error:
reading file ./BigLogo.dat
writing file ./symbol.BigLogo.pak
packing symbol.BigLogo
reading file ./builder_cursor.dat
writing file ./cursor.Builder.pak
packing cursor.Builder
reading file ./marked.dat
writing file ./cursor.Marked.pak
packing cursor.Marked
Executing command: lift symbol.BigLogo.pak
Merging: makeobj QUIET merge GUI.128.pak *.pak
writing file GUI.128.pak
copying file GUI.128.pak
Makeobj call returned -11
When I want to test it "by Hand" I have the problem, that I don´t understand at wich Part of the PAK the makeobj have a Problem ... could somebody help?
Withaut I could not identify if it a makeobj or a PAK128 problem ....
Werner
Edit:Not a PAK128 Problem, it is an makeobj Problem and must solve there
If it's a recent pakmak.py, the mesages should match (since std* are now flushed after every call). That means this happens:
1) gui paks are compiled - ok
2) biglogo is copied - ok
3) merging the rest to one file <- error
Does it work with normal makeobj?
It work with the offizial makeobj
And with a compiled from Version r3164 (But this have an other problem)
But r3301 take this problem!
I want to test it by Hand to better make a Bug reporting for makeobj (or PAK128), bu I don´t understand wich part I can do "by Hand", I could write in the shell to see the problem.
Edit:
Normaly makeobj return only 0,1,3. But in this case it is -11??
Edit2:
Sorry, use the Wrong Version-Number. A simple copy-and-paste-problem. Now the Bugmessage is correct
Maybe makeobj exit is strange and python reads wrong exit code? I will test in the afternoon...
If you need I could give you my makeobj (linux64) or could crosscompile a makeobj for you ....
I'll test "latest" (r3303) on windows. If you can give me 32-bit version for linux, I will try to test that, too.
3303 @ win = no fail ;)
I am interested in that -11; if return codes are returned as bytes, then it's the same as 245...
Can you test the operations manually, if they return bad codes outside pakmak? The first is
makeobj QUIET pak128 ./ ./
and second
makeobj QUIET merge GUI.128.pak *.pak
edit: you can try without QUIET (then it will write also lots of "makeobj version blah blah markus pristovsek volker meyer blahblah")
Its crasy, with 3303 work it at my system too..
I make a retest with 3301.. it Works!!
But there was no change in the PAK (svn log)
I don´t understand it ....
At now it don´t work :o(
Wit 3303 and 3303-32Bit ...
Makeobj call returned -11
Die letzten Meldungen:
Generieren Open-PAK128 schlug Fehl
writing file ./symbol.Builder.pak
packing symbol.Builder
reading file ./construction.dat
writing file ./misc.Construction.pak
packing misc.Construction
reading file ./generaltools.dat
writing file ./cursor.GeneralTools.pak
packing cursor.GeneralTools
reading file ./BigLogo.dat
writing file ./symbol.BigLogo.pak
packing symbol.BigLogo
WARNING: ignoring alpha channel
reading file ./builder_cursor.dat
writing file ./cursor.Builder.pak
packing cursor.Builder
reading file ./marked.dat
writing file ./cursor.Marked.pak
packing cursor.Marked
Executing command: lift symbol.BigLogo.pak
Merging: makeobj QUIET merge GUI.128.pak *.pak
But when I do it "per Hand" I get "no Problem"
makeobj QUIET merge GUI.128.pak *.pak
I get no problems with v50 from sourceforge.
The version you sent me does not work ("bash: can not execute binary file"). Of course with executable bits on ;D
64 versus 32 bits?
I don't think so... According to Werner the binary was 32bit and the system was 32bit when I installed it. Only if Ubuntu upgrade changes to 64 bits without asking... but that is fantasy.
Can you test it again?
But its now makeobj.51.r3330.32Bit on the same place
It could be that the crosscompiling for 32 Bit for makeobj is broken ... so I compile it on my Notebook....
Sorry, still the same...
did you load binary or ascy??
I recheckt it and it work on a 32Bit-System ......
Chmod 755... am I missing something here?
Wich do you download??
On my SystemI must not make "chmod +x" .... but i set the ftp-programm to download binary ...
And i Donwload from my Webside and test ... and the makeobj.51.r-3330.32Bit work ....
I downloaded it with wget, set mode and copied to /usr/bin/, then added symlink called makeobj.
I don´t know how whe solfe the Problem ... :o(
When I test it, it works ....
Do you need some feature from this makeobj testing build? If no, let's wait a week and try again :P
edit: or I could try to compile myself! Oh no... :-(
edit 2 : compiled, tested, reproduced. It happens with different file. This will be hard to debug... maybe the bug is in python library? I'll try more...
I need the makeobj for the PAK64 ... and I would not use different makeobj for different PAKs ....
Give you me a Message when you find the error??
Sure, I will.
Thanks ...
A few moments of testing showed, that it can be reproduced. I haven't tested yet if the output is valid pak or not. The virtual machine is... slow.
What happens? Negative return is "special feature" of the library and means that process terminated with signal.
-11 = signal #11 = SIGSEGV. Boo.
If I have some more time to kill by the virtual machine, I'll "playtest" outputs.
note: makeobj compiled myself.
So it is an pyhon, an mose or an makeobj Problem?
Makeobj. When you do makeobj merge target.pak *.pak, it can break. In some cases it gets sigsegv as seen here. But it can go recursive and write the file to itself again and again... :-( That just happened to me.
so whe must write a "Bug-Report" für makeobj??
Done... http://forum.simutrans.com/index.php?topic=5218.0
So it is an makeobj and not an PAK128 error and we can clouse this Errormessage