Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Infrastructure → Build environment
  • Assigned To No-one
  • Operating System Another
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.4
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by yzflcyq - 2010-03-21
Last edited by roolku - 2010-04-04

FS#11134 - Errors with 'rockboxdev.sh' (or my Cygwin?)

  I've installed Cygwin and synchronized the source code of Rockbox.
  I 'm going to make a build for my Onda VX747 on Windows XP.I know I must install cross compiler first so I run the 'rockboxdev.sh'.
  There must be something wrong with my Cygwin.How could it happened!
Administrator@PC-200908211640 ~
$ cd rock/tools
Administrator@PC-200908211640 ~/rock/tools
$ sh rockboxdev.sh
rockboxdev.sh: line 2: $’\r’: command not found
rockboxdev.sh: line 7: $’\r’: command not found
rockboxdev.sh: line 11: $’\r’: command not found
rockboxdev.sh: line 17: $’\r’: command not found
rockboxdev.sh: line 21: $’\r’: command not found
rockboxdev.sh: line 45: syntax error near unexpected token `$’{\r’’ ‘ockboxdev.sh: line 45: `findtool(){
Closed by  roolku
2010-04-04 08:26
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

r25310

Try dos2unix or saving rockboxdev.sh in a text editor with unix style line endings. It appears the sh shipped with cygwin doesn’t understand windows-style line endings (\r\n instead of plain \n).

Robert - are you sure that r25310 is needed, and that it will solve yzfloyq’s problems?

It appears that yzfloyq has checked out the source code from svn using a Windows client (tortoise?), but is then trying to use that checkout in an environment (Cygwin) which expects files with Unix line-endings. I wouldn’t expect that just fixing rockboxdev.sh would be enough - other problems will happen when Rockbox itself is compiled.

I don’t know how well it works, but Cygwin can be configured to work with DOS line-endings. If that was working before r25310, then it may now be broken.

I would have expected the solution to be for yzfloyq to checkout the source correctly - i.e. with a client that uses the same line-endings as Cygwin. So this is not a bug, and didn’t need fixing.

Dave wrote:

I don’t know how well it works, but Cygwin can be configured to work with DOS line-endings.

To my knowledge this is not the case any more with version 1.7. I just did a test install and it didn’t offer the option. Unfortunately I haven’t been able to find any release notes explaining it, only http://cygwin.com/faq/faq-nochunks.html#faq.api.cr-lf which seems to put the onus on the program to deal with both types of endings. And in fact the vast majority of the tools do. It is surprising that sh doesn’t.

AFAIK “configured to work with DOS line-endings” means that directories are mounted with option “text”. Since version 1.7 mount points are stored in the windows registry, so it is not straight forward to access and modify them.

As an experiment I manually mounted a directory as text from the command line, checked out a fresh copy of rockbox and tried to build. It failed half way through the build:

CC apps/menu.c
/home/robert/a/apps/menu.c: In function ‘do_menu’:
/home/robert/a/apps/menu.c:454: error: ‘LANG_TOP_QS_ITEM’ undeclared (first use in this function)
/home/robert/a/apps/menu.c:454: error: (Each undeclared identifier is reported only once
/home/robert/a/apps/menu.c:454: error: for each function it appears in.)
/home/robert/a/apps/menu.c:454: error: ‘LANG_LEFT_QS_ITEM’ undeclared (first use in this function)
/home/robert/a/apps/menu.c:454: error: ‘LANG_BOTTOM_QS_ITEM’ undeclared (first use in this function)
/home/robert/a/apps/menu.c:454: error: ‘LANG_RIGHT_QS_ITEM’ undeclared (first use in this function)
make: *** [/home/robert/a/test/apps/menu.o] Error 1
rm /home/robert/a/test/apps/bitmaps/native/default_icons.6x8x16.c /home/robert/a
/test/apps/bitmaps/native/rockboxlogo.240x74x16.c /home/robert/a/test/apps/bitmaps/native/usblogo.176x48x16.c

(quick guess something went wrong with the language files, buit I didn’t follow it up)

I tried the same but using cygwin svn to check out the tree (surprisingly the files had LF endings!). Same result.
I checked out with tortoisesvn into a directory that was binary mounted. (CRLF endings) It built without issues.

While the advice to use cygwin “configured to work with DOS line-endings” has been given a few times in the forums (mainly by UNIX users afaict) I have never seen a report of it actually working. Quite the opposite.

On the other hand I have been using cygwin with tortoisesvn (windows line endings) almost exclusively with no problems (The reason I have never encountered the rockboxdev.sh issue is that I am using LINUS’ packages.). So while the “cleaner” solution would be to have native line endings, I think the pragmatic approach is to change the shell scripts to LF. I can’t see a situation where I wanted to have a shell script to have DOS line endings. Personally I would go as far as changing all shell scripts in rockbox to svn-eol: LF .

Can’t you configure the line endings tortoisesvn? If yes, I think it would be enough to require one to do that.

Annoyingly no. It was possible in TortoiseCVS but in SVN it is controlled by the attribute and the client hast no say. :(

It would defeat the purpose of the svn:eol-style property if the client could control this. You can always run dos2unix (or something similar). Another option is to not set svn:eol-style at all, then svn will always use line endings as-is.

You can always run dos2unix (or something similar).

I don’t consider this a solution. It would have to be reverted before every commit and it is a nuisance to remember to do for every new checkout. Not to mention the “bug reports” like the one here.
Computer should make life easier not harder.

Another option is to not set svn:eol-style at all, then svn will always use line endings as-is.

That would be okay but I am not sure what the advantage is. It is equivalent to changing the style to LF isn’t it?

I don’t consider this a solution. It would have to be reverted before every commit and it is a nuisance to remember to do for every new checkout.

Well, I don’t think this would be an issue for people with commit access. Using an svn client in the correct environment also doesn’t create a problem: when running a Unix-like environment the svn client should also be a unix client, thus svn:eol-style=native resulting in the correct line endings. If people decide to mix environments (like Cygwin with LF line endings and TortoiseSVN which are different environments) they need to live with the resulting incompatibilities. The same way you can’t expect to create a binary for Linux to run on Windows. And we’re talking about rockboxdev.sh here which you need to run rarely anyway.

Computer should make life easier not harder.

This problem is caused by the user mixing up different environments. This is clearly a user error, nothing a computer is responsible for. Therefore I don’t consider computers making life harder here, it’s a user issue.

That would be okay but I am not sure what the advantage is. It is equivalent to changing the style to LF isn’t it?

Not exactly. Without svn:eol-style line endings are committed as-is, i.e. no translation at all happens. Thus you can even commit files with mixed line endings and will get exactly that on checkout. If the file is saved with LF before committing then it is equivalent, but only in that case.

I am afraid I don’t get your point. What exactly is the disadvantage of rockboxdev.sh having linux line endings?

It appears that roolku hasn’t just changed rockboxdev.sh to use eol-style=LF, but other files as well. e.g. the eol-style property of tools/configure was changed as part of an unrelated commit in r12555, and without any mention in the commit message. r17423 made the same change to tools/version.sh, with the commit message “same for svnversion.sh”

Also, various perl scripts (genlang, wpsbuild.pl) contain code to strip CR characters from input files.

So (unnoticed by me), Rockbox will indeed build fine when the source code is checked out with a client where DOS line-endings is “native”. I don’t have a problem with that (or setting all shell scripts to eol-style=LF), but wish it had all been done a bit more explicitly.

I’ve now learnt that a) Rockbox can be built with source files and scripts (apart from shell scripts) containing DOS line endings; and b) Cygwin’s “DOS line-endings” mode is completely broken, and should never have been suggested to people. Fortunately cygwin have now dropped that feature.

So I tried to download the source again with svn under Cygwin and it works!Thanks for everyone’s help.Please close this topic.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing