Bug #3740

Can't compile grfcodec anymore

Added by Snail over 7 years ago. Updated over 7 years ago.

Status:ClosedStart date:2012-02-26
Priority:NormalDue date:
Assignee:-% Done:


Target version:-


Hi all,
I tried to get the source code and compile it (I'm using Mac OS X 10.6.8), but it looks like the compiling cycle goes to an endless loop.
When I enter "make all", the following lines appear:

/bin/sh: line 0: [: =: unary operator expected
[LD] objs/endian_check
[ENDIAN] Determining endianness

followed by the list of single files; " [CPP DEP] objs/pseudo_seq.o.d " is the first and " [CPP DEP] objs/pcxfile.o.d " is the last. After this one, the same three lines I wrote above are displayed, followed by the same list of files. And so on.

However, when I compiled the previous versions (5.1.3 and r900), this problem didn't occur and they got correctly compiled...


#1 Updated by Rubidium over 7 years ago

Does r900 really work? As what you tell sounds like a Makefile issue, but the Makefile hasn't changed since long before r900.

So have you really tried r900 with the currently installed development tools? Or was it that the previous compile of r900 just succeeded, but now you updated GRFCodec it fails? If the latter is the case, then something else has most likely caused this problem.

#2 Updated by Snail over 7 years ago

I compiled and ran r900, and used it to code my NFO file to a GRF. It worked without problems, and the final GRF correctly works with OTTD. The only problematic thing was nforenum reporting cargo property 0A for railtypes as an error (while it's the new custom tunnel portal feature instead).

As for r915, I'm trying to compile it and getting through the loop I just described.

Mind you, even compiling r900 displayed the initial three lines:

/bin/sh: line 0: [: =: unary operator expected
[LD] objs/endian_check
[ENDIAN] Determining endianness

However, after ending the final file:

[CPP DEP] objs/pcxfile.o.d

these lines were displayed:

/bin/sh: line 0: [: =: unary operator expected
[CPP] objs/grfcomm.o
[CPP] objs/pcxfile.o

and from there, the various programs were compiled. This doesn't happen anymore with r915.

#3 Updated by Rubidium over 7 years ago

I have absolutely no clue what is going wrong. The Makefile changes have not touched one of the lines that could cause that warning/error message. Neither do the changes look like they would influence the calling of that code.

Does a make clean and then making it help at all?

#4 Updated by Snail over 7 years ago

Unluckily, even make clean enters in the same infinite loop...

OTOH, I just tried to re-make r900, and it works. Perhaps I'll try with the next nightly and see if the problem persists?

#5 Updated by andythenorth over 7 years ago

i just built r915 on 10.6.8 successfully. ('make clean' then 'make all')

Could it be a gcc issue or such? My guesses about causes are normally wrong tbh :)

#6 Updated by planetmaker over 7 years ago

Another random idea: what gives

libpng-config --version

#7 Updated by Snail over 7 years ago

Hi, I tried again with the current nightly (r920) and the problem persists...

#8 Updated by Rubidium over 7 years ago

The problem will persist as long as we don't know what the problem is. Even those which have the most similar system to yours I could find could not reproduce it, so it must be something special to your system. That it worked in the past, given that it already gave errors, is more a fluke. After all, nothing changed to the building since r900.

#9 Updated by Snail over 7 years ago

Is there anything I can try to find out what the problem is? For instance, editing some files?

#10 Updated by Snail over 7 years ago

The problem is sorted now. Thank you!

#11 Updated by Rubidium over 7 years ago

  • Status changed from New to Closed

The warning should be solved in tarballs since r922

Also available in: Atom PDF