Code::Blocks Forums

User forums => Using Code::Blocks => Topic started by: lindquist on November 12, 2005, 08:14:20 am

Title: rc2 - bad tgz source package
Post by: lindquist on November 12, 2005, 08:14:20 am
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!
Title: Re: rc2 - bad tgz source package
Post by: takeshimiya on November 12, 2005, 09:22:20 am
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?
Title: Re: rc2 - bad tgz source package
Post by: thomas on November 12, 2005, 01:05:25 pm
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.
Title: Re: rc2 - bad tgz source package
Post by: takeshimiya on November 12, 2005, 01:30:29 pm
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:
Title: Re: rc2 - bad tgz source package
Post by: thomas on November 12, 2005, 01:49:47 pm
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.

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.
Title: Re: rc2 - bad tgz source package
Post by: takeshimiya on November 12, 2005, 02:06:37 pm
I never talked about GCC (it's good :P), I stated autotools and most linux command line tools doesn't currently handle CR+LF
Title: Re: rc2 - bad tgz source package
Post by: lindquist on November 12, 2005, 08:02:27 pm
I don't see any point in taking all these measures to avoid this mistake.
If just the source distributions would use the correct EOLs it not a problem IMO.
People doing CVS checkouts on Windows and compiling them on linux seems like a rather weird usage pattern to me.

Conclusion: Make the tgz on a linux machine = problem solved
Title: Re: rc2 - bad tgz source package
Post by: takeshimiya on November 12, 2005, 09:29:03 pm
Well, that's exactly what doesn't happened in RC2, mainly probably because the tarball was created on windows... And the devs was at that time on windows.
So it seems that each time to make a release they'll have to switch to a linux box to create it, which is not bad, but it's rather overkill (or not feasible if they don't have a linux box atm) only for those EOL issues...
Title: Re: rc2 - bad tgz source package
Post by: sethjackson on November 12, 2005, 09:41:46 pm
Quote from: lindquist on November 12, 2005, 08:02:27 pm
I don't see any point in taking all these measures to avoid this mistake.
If just the source distributions would use the correct EOLs it not a problem IMO.
People doing CVS checkouts on Windows and compiling them on linux seems like a rather weird usage pattern to me.

Conclusion: Make the tgz on a linux machine = problem solved

Isn't there a Linux program called dos2unix that converts the EOL? Maybe you could use that.
Title: Re: rc2 - bad tgz source package
Post by: takeshimiya on November 12, 2005, 10:30:15 pm
It is indeed, and that's what ALL linux users needs to do in RC2 to get autofriends right with LF:

find . -type f -and -not -name "*.png" -and -not -name "*.bmp" | sed "s/.*/\"\\0\"/" | xargs dos2unix
find . -type f -and -not -name "*.cpp" -and -not -name "*.h" -and -not -name "*.png" -and -not -name "*.bmp" | sed "s/.*/\"\\0\"/" | xargs dos2unix