make failing: /usr/bin/sh: .lss: No such file or directory

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello All,

I've been running avr-gcc, as part of WinAVR 2010-01 in XP in a VirtualBox emulation, for quite some time.

Everything was working fine until I started receiving this error:

Creating Extended Listing: PrinterHost.lss
avr-objdump -h -S -z PrinterHost.elf > PrinterHost.lss
/usr/bin/sh: PrinterHost.lss: No such file or directory
make: *** [PrinterHost.lss] Error 1

(this error started after a windows crash from a corrept usb flash drive. I'm not sure if this is the cause, or if it's something else I changed in the project. I reinstalled WinAVR and AVRstudio4 without helping.)

No PrinterHost.lss is created, however if I run the avr-objdump command line in a dos box, it completes successfully.

Another strange symptom is that "make clean" doesn't delete the .o/.lst/.lss/.hex/.elf files in the project directory. So another possible scenario I'm wondering about is that somehow windoze is confused by the mixed case names that are resident in the unix file store behind the virtualbox emulation.

Any help would be _very_ greatly appreciated!

johnea

p.s. I posted this first to avr-gcc list, but this seems a more WinAVR issue, so I reposted here.

p.p.s. I also posted there that I had some warnings WRT progmem, I've eliminated all of those warnings, still getting the error above.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

More clues,

I'm also seeing the flippin Error Code: -2147467259 on AVRstudio opening the project:

Loaded plugin STK500
Loaded plugin AVR GCC
Loaded partfile: C:\Program Files\Atmel\AVR Tools\PartDescriptionFiles\
Error Code: -2147467259:

That's some error code 8-)

I also tried changing the makefile to eliminate the -f from the rm used during "make clean", like so:

REMOVE = rm 
#REMOVE = rm -f

This caused the following errors when I try to make clean:

Cleaning project:
rm PrinterHost.hex
rm: cannot remove `PrinterHost.hex': No such file or directory
make: *** [clean_list] Error 1
Build failed with 1 errors and 0 warnings...

However PrinterHost.hex is seen in the directory by windoze and the linux host:

W:\trunk\Demos\Host\LowLevel\PrinterHost> dir PrinterHost.*
Volume in drive W is VBOX_work
Volume Serial Number is 0000-0904

Directory of W:\trunk\Demos\Host\LowLevel\PrinterHost

09/27/2010 06:07 PM 239,000 PrinterHost.lst
09/27/2010 06:02 PM 3,125 PrinterHost.h~
09/27/2010 06:07 PM 99,382 PrinterHost.elf
09/27/2010 06:02 PM 3,039 printerhost.aps
09/27/2010 06:02 PM 1,728 PrinterHost.txt
09/27/2010 06:07 PM 82,330 PrinterHost.map
09/27/2010 06:07 PM 56,603 PrinterHost.hex
09/27/2010 06:07 PM 13 PrinterHost.eep
09/27/2010 06:02 PM 310,814 PrinterHost.lss
09/27/2010 06:02 PM 25,451 PrinterHost.c
09/27/2010 06:02 PM 25,580 PrinterHost.c~
09/27/2010 06:02 PM 272 printerhost.aws
09/27/2010 06:07 PM 59,332 PrinterHost.o
09/27/2010 06:02 PM 3,168 PrinterHost.h
09/27/2010 06:03 PM 3,039 printerhost.aps~
15 File(s) 912,876 bytes
0 Dir(s) 952,124,067,840 bytes free

All the files are clearly there, this has me dead in the water. My development came to a grinding halt when this popped up.

Thank You Very Much for any help getting the build running here again!!!

johnea

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

johnea wrote:
I'm also seeing the flippin Error Code: -2147467259 on AVRstudio opening the project
Run a forum search on this error code. It's been discussed (and solved) several times before. I'd tell you the answer but, to be honest, I cannot remember the solution myself.

As for the first problem, make sure that the environment variables TEMP and TMP point at a valid directory that you have permission to write. I'm not sure that this is the problem, though.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

It's been discussed (and solved) several times before.

There's only one thread with substance in it. At least after a search for that error code. And even that thread is "thin", with no real resolution but "It's a 'general error'":

https://www.avrfreaks.net/index.p...

I'd start with the usual suspects:
- The project file might simply be broken. Roll in yesterdays backup copy from your backup medium. Oh, you havent't... Well, then you..
- Create a new project and add (copies of) all the source files to that one.
- De-install/re-install. Some binary software file or similar might be broken. Both AVR Studio and WinAVR!
- Turn off antiviral software, at least for a short test period. It might hook accesses in an improper way, or AVR Studio might do accesses in a suspicious way, or...
- Place the project in a folder close to the root, with no white-spaces or national characters in the path.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks so much for the suggestions!

I had read the thread on the "Unspecified Error", as well as posts in various other places around the interweb.

Stu, chances are you don't remember the exact resolution because there really wasn't one.

This error seems to come up in numerous, seemingly unrelated, contexts. It may or may not have anything to do with my difficulties. (what the heck is an "unspecified error" anyway? I spit on the ground in the general direction of redmond, schptuwey! 8-)

I tried reinstalling avrstudio, winavr, my project files from backup. Nothing helped.

This issue is some sort corruption in the cursed binary database of secret knowledge (the registry) or corruption of some system driver or dll that was not repaired by the reinstallation of both studio and winavr (including re-installing the jungo drivers).

My final workaround (not solution) was to restore the VirtualBox disk image from backup (basically rolling back the whole windows install)

The project files are on the linux host. The windows install "sees them" via an emulated disk share. The same project and source files that failed yesterday are compiling now. Oh well, at least it's building...

[rant on]
This just speaks again to the issue of having the most recently patched version of the toolchain only running on windoze.

This applies to debug even more than compilation. avrstudio is really the only application left that I still have to go to windoze emulation for. And quite frankly, it's really not that good.

I routinely have:
- single steps that launch off into unstopped execution
- inability to view certain data types, even when they are still in scope
- various other aperiodic irregularities in single stepping and running to cursor

Why can't semi-condiuctor manufacturers get it through the heads of their marketing twits that making it _harder_ to debug firmware doesn't increase sales!

This along with the fact that we haven't seen a technological advance in in-circuit debug capability in over a decade!
[/rant off]

Whew.., OK I think I feel better now 8-)

I'm back to solving the client's issues at this point.

Thank You Very Much! to both Johan and Stu for your supportive replies. Your time in composing thoughtful suggestions is a great contribution.

Back to the grind...

johnea

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I routinely have:
- single steps that launch off into unstopped execution

Not in the Asm view I'll warrant ! Don't single step optimized C.

See this which explains most of the "odd" behaviour you might see when debugging optimized code:

Optimization in GCC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

johnea wrote:
avrstudio is really the only application left that I still have to go to windoze emulation for. And quite frankly, it's really not that good.

Then drop it and learn to debug without OCD.

Remember, that the real debugger sits on your chair and not in that plastic box.

It's not that hard than it looks (it's certainly less hard than the toolmakers want you to believe it is), OCD is good only for trivial errors anyway, and the independence from tools of that kind will free you up in many respects.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
johnea wrote:
avrstudio is really the only application left that I still have to go to windoze emulation for. And quite frankly, it's really not that good.

Then drop it and learn to debug without OCD.

Remember, that the real debugger sits on your chair and not in that plastic box.

It's not that hard than it looks (it's certainly less hard than the toolmakers want you to believe it is), OCD is good only for trivial errors anyway, and the independence from tools of that kind will free you up in many respects.

JW

While I totally agree that the engineer is the real debugger, I have to disagree with in-circuit debug not being useful.

My personal background is 27 years in industry as an embedded systems engineer, with 10 of those years working for 8-bit semiconductor manufacturers.

While the thinking and logic is clearly in the domain of the designer/debug engineer, there is no substitute for the insight into internal operation provided by a debug interface.

No amount of simulation or thought experiment can provide the data of direct oberservation.

The debugger is an augmentation to the creativity and experience of the designer, not a substitute.

8-bit micro debug technology made a step forward when several 8-bit micro makers adopted in-circuit debugging in the mid-90s. There really hasn't been any progress since. In fact the obfuscation of communications protocols and the development of tools soley by internal groups (comprised largely of people who have never done other embedded sytem development) has been a mill-stone on the neck of facilitating ready debug in 8-bit micro environments for it's entire history.

In recent years the open-source world has made significant headway in bringing toolchains to bear that free the developer of the yoke of corporate marketing control over their work.

I'm hoping we continue to see more open-source inroads into the run-time debug aspect of embedded software development.

The cooperative support provided on forums like this is a perfect example of what happens when corporate marketing is removed from the loop.

Thanks for all the help!

johnea

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

johnea wrote:
While I totally agree that the engineer is the real debugger, I have to disagree with in-circuit debug not being useful.

I didn't say that.
I wrote:
OCD is good only for trivial errors anyway

That's still quite useful, for beginners and trivial applications (there must be loads of them around).

I'd like to add, OCD is also good as a fancy albeit clumsy replacement for debug printouts and their equivalents.

johnea wrote:
While the thinking and logic is clearly in the domain of the designer/debug engineer, there is no substitute for the insight into internal operation provided by a debug interface.
That insight is supposed to be fully provided by the datasheets and associated documentation. I am not going to discuss their quality (and decline of that) here.

Nevertheless, OCD is a good tool for beginners to get grasp of what happens in the chip, I agree. Beyond that, I, as a software engineer, MUST know EXACTLY how the commands I write are executed. I may write erratic commands, and I do, but inspecting these commands - with the help of inspecting the behaviour of the program - I am (or should be) able to fully deduce the internal operation of the chip.

JW

PS Re your original problem: as you might have guessed I dont use AVRStudio, but I would have a look at the project files and/or any other files that might be associated with the project (including ini files of AVRStudio itself, it any), and/or AVRStudio-related keys in the registry, and inspect the paths to your project folder there. Haven't you by chance changed the directory structure after the crash?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

My final workaround (not solution) was to restore the VirtualBox disk image from backup (basically rolling back the whole windows install)

Oh..Virtual Box. While it is one of my fairly new favourite things, I'd risk wagering a beer that something went awry there, or VBox not fully supporting some Windoze file system quirk or some such..

You do know that you can "snapshot" a good VBox setup, so you really don't need to roll in a backup? (It will of-course cost you disk space, but if your install is fragile and you need to redo this rollback then you might be better off with a good snapshot.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So Johnea, did you check out Bingo600's Linux scripts? You would need to use gdb for your debugger and something other than AVR Studio as our IDE (there's both Eclipse and Code::Blocks, or whatever you like), but otherwise it all seems to be supported.

Rumor has it that the Atmel is going to Eclipse for the next version of AVR 8-bit tools anyway, so native Linux support is (hopefully) on the way.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Quote:

It's been discussed (and solved) several times before.

There's only one thread with substance in it. At least after a search for that error code. And even that thread is "thin", with no real resolution...
johnea wrote:
Stu, chances are you don't remember the exact resolution because there really wasn't one.
You are both quite right. There is no thread giving a solution to this problem. Sorry guys, old guy memory. :oops:

Johnea, I know you have solved the problem, albeit notiun the way you would have liked. After a search of MSDN on this problem, it appears there are a plethora of possible causes; well, duh, the error code means "unknown error"! I know that I have run into something like this, though.

One other thing to look at: I seem to remember a problem with AVR Studio that was caused by the temp directory getting set as "read-only" (or perhaps non-existent). The thread was in the AVR Studio forum and was a few months back. Of course this is the "old guy memory" speaking again :lol:! Since you are running from Vbox, might there be some kind of similar problem there? I run Vbox, but the other way (Linux on Windows).

I'm glad you're off the dime. Best of luck!

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:

Oh..Virtual Box. While it is one of my fairly new favourite things, I'd risk wagering a beer that something went awry there, or VBox not fully supporting some Windoze file system quirk or some such..
You could be right in this. Although I have to say, I've been using this setup for about 2 years and it's been very stable. VirtualBox USB emulation has worked really well with JTAGICE-mkII / Jungo / AVRstudio. I can even load/unload the driver in windows by checking and un-checking the box next to the jtagice in the device menu.

I tried snapshots at one point but they had some other undesirable sid eeffect that kept me from using them. I just copy the whole vdi file for backup.

stu_san wrote:
You are both quite right. There is no thread giving a solution to this problem. Sorry guys, old guy memory.
No worries Stu. I know exactly how you feel. When youv'e watched several generations of technology come and go in the course of a career something's got to slip somewhere 8-)

The -2 bazillion error by-the-way, still occurd after rolling back the install, and wasn't distrupting operations at all. It seems it wasn't at the core of the error.

Anyway, things are moving ahead again now.

Thanks to everyone for their suggestions! Every new perspective is helpful...

johnea