User forums > Using Code::Blocks

rc2 - bad tgz source package

(1/2) > >>

lindquist:
I just downloaded the tgz source package as I want to try this baby out on my CRUX Linux machine.
I only get a :bad interpreter: error thing...

The unix package should not use Windows line endings... It breaks it!

Guess I'll try a CVS checkout instead.... This was just really annoying and it took me a while to figure out what was happening.
Thanx whoever made the wiki entry!

takeshimiya:
Those CR+LF were left by accident.

Anyways, this kind of things makes me think if it wouldn't be better if all source files of C::B were always LF instead of OS dependant... instructing all the CVS/FTP clients/(servers?) and Code::Blocks itself to not change the EOL mode.

The MSVC compiler supports LF line endings, even the IDE supports editing with LF line endings as something normal.
So perhaps the only 'useful' (:?) text editor in Windows that doesn't support LF line endings is Notepad.

What do you think of going LF all the way?

thomas:
Version control converts line breaks to whatever is native on the platform you check out. Unless someone messes with that by accident this works really fine everywhere.
Since this is the exception, and not the rule, I think it is best to leave it like this. It is of course possible to configure version control not to perform line end conversions, but then the devs would run into problems when developing on different platforms. So this would mean trading an exceptional problem for a constant problem.

takeshimiya:
LF works with almost 90% of current applications on any system.
Current compilers and IDEs can cope with it in any actual OS.

Unless you want to not have problems with older win32/mac applications like MSVC6 or Notepad, it's not a problem.

If we were talking about "\" "/" slashes for paths, or unicode, that's an issue still today, but EOL issues are more of the past.

This would also solve the problem of "I did a checkout with CVS in windows and then I tried to compile in linux, with errors" kind of posts.

The autotools and most linux command line tools doesn't currently handle CR+LF.
But on MSW/MAC/Any other OS, it's well supported by now, and I didn't hear any problems related to LF issues in windows using C::B.

But well, this it's not so a problem if this never happens again to anyone here... :roll:

thomas:
Apart from that, it surprised me that the compiler would complain, so I tried myself:

--- Code: ---bash-3.00$ cat crlf.c
int main()

{




return 0;
};
bash-3.00$ hexdump crlf.c
0000000 6e69 2074 616d 6e69 2928 0a0d 0a0d 0d7b
0000010 0d0a 0d0a 0d0a 0d0a 720a 7465 7275 206e
0000020 3b30 0a0d 3b7d 0a0d
0000028
bash-3.00$ gcc crlf.c
bash-3.00$ gcc --version
gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--- End code ---

As can be seen in the hexdump, there are many 0a0d in this file, but the compiler does not seem to bother...?

It is of course disturbing if you see double linefeeds in an editor because of CRLF conversion issues, but that is an entirely different subject - we're talking about a broken compile.

Navigation

[0] Message Index

[#] Next page