Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

uzebox_src_3.1.zip does not compile properly under linux #11

Closed
GoogleCodeExporter opened this issue Mar 15, 2015 · 11 comments
Closed

uzebox_src_3.1.zip does not compile properly under linux #11

GoogleCodeExporter opened this issue Mar 15, 2015 · 11 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. Download uzebox_src_3.1.zip from the "Downloads" sidebar at 
http://code.google.com/p/uzebox/ .
2. Extract the zip file to a folder.
3. Change directories into the output folder
4. Run 'make'.

What is the expected output? What do you see instead?
I expect it to compile all of the software. Instead, I see
<code>
aaron@aaron-laptop:~/src/uzebox_src_3.1$ make
make -C tools/uzem  DEST_DIR=/home/aaron/src/uzebox_src_3.1/bin/
make debug
=================================
Building Debug...
Platform: Unix-LINUX
=================================
g++ -c uzem.cpp -o Debug/uzem.o -I/usr/local/include/SDL -D_GNU_SOURCE=1 
-D_REENTRANT -DLINUX -D_GNU_SOURCE=1 -DGUI=1 -g -MD -MP -MF Debug/uzem.d 
-DUSE_PORT_PRINT=1 -DUSE_SPI_DEBUG=1 -DUSE_EEPROM_DEBUG=1 
-DUSE_GDBSERVER_DEBUG=1
g++ -c avr8.cpp -o Debug/avr8.o -I/usr/local/include/SDL -D_GNU_SOURCE=1 
-D_REENTRANT -DLINUX -D_GNU_SOURCE=1 -DGUI=1 -g -MD -MP -MF Debug/avr8.d 
-DUSE_PORT_PRINT=1 -DUSE_SPI_DEBUG=1 -DUSE_EEPROM_DEBUG=1 
-DUSE_GDBSERVER_DEBUG=1
avr8.cpp: In member function ‘void avr8::SDBuildMBR(SDPartitionEntry*)’:
avr8.cpp:2043: warning: format ‘%d’ expects type ‘int’, but argument 2 
has type ‘size_t’
g++ -c uzerom.cpp -o Debug/uzerom.o -I/usr/local/include/SDL -D_GNU_SOURCE=1 
-D_REENTRANT -DLINUX -D_GNU_SOURCE=1 -DGUI=1 -g -MD -MP -MF Debug/uzerom.d 
-DUSE_PORT_PRINT=1 -DUSE_SPI_DEBUG=1 -DUSE_EEPROM_DEBUG=1 
-DUSE_GDBSERVER_DEBUG=1
g++ -c gdbserver.cpp -o Debug/gdbserver.o -I/usr/local/include/SDL 
-D_GNU_SOURCE=1 -D_REENTRANT -DLINUX -D_GNU_SOURCE=1 -DGUI=1 -g -MD -MP -MF 
Debug/gdbserver.d -DUSE_PORT_PRINT=1 -DUSE_SPI_DEBUG=1 -DUSE_EEPROM_DEBUG=1 
-DUSE_GDBSERVER_DEBUG=1
gdbserver.cpp: In member function ‘void GdbServer::gdb_write(const void*, 
size_t)’:
gdbserver.cpp:265: warning: format ‘%d’ expects type ‘int’, but 
argument 3 has type ‘size_t’
g++  Debug/uzem.o  Debug/avr8.o  Debug/uzerom.o  Debug/gdbserver.o -o 
/home/aaron/src/uzebox_src_3.1/bin//uzemdbg -I/usr/local/include/SDL 
-D_GNU_SOURCE=1 -D_REENTRANT -DLINUX -D_GNU_SOURCE=1 -DGUI=1 -L/usr/local/lib 
-Wl,-rpath,/usr/local/lib -lSDL -lpthread -DUSE_PORT_PRINT=1 -DUSE_SPI_DEBUG=1 
-DUSE_EEPROM_DEBUG=1 -DUSE_GDBSERVER_DEBUG=1
/usr/bin/ld: cannot open output file 
/home/aaron/src/uzebox_src_3.1/bin//uzemdbg: No such file or directory
collect2: ld returned 1 exit status
make[2]: *** [/home/aaron/src/uzebox_src_3.1/bin//uzemdbg] Error 1
make[1]: *** [all] Error 2
make: *** [tools/uzem] Error 2
</code>

It appears as if there is no ./bin directory.
'ls' confirms this.
<code>
aaron@aaron-laptop:~/src/uzebox_src_3.1$ ls
demos  gfx  gpl-3.0.txt  kernel  Makefile  README.txt  tools
</code>

I then created 'bin' folder in the current directory.
Running 'make' then compiled the tools, but could not compile the demos 
properly.
<code>
aaron@aaron-laptop:~/src/uzebox_src_3.1$ make demos
make -C tools/packrom  DEST_DIR=/home/aaron/src/uzebox_src_3.1/bin/
make debug
=================================
Building Packrom Debug...
Platform: Unix-LINUX
=================================
done!
make release
=================================
Building Packrom Release...
Platform: Unix-LINUX
=================================
done!
===================================
Building demo: demos/Arkanoid/default
===================================
make -C demos/Arkanoid/default 

../../../tools/packrom/packrom Arkanoid.hex Arkanoid.uze ../gameinfo.properties
make[1]: ../../../tools/packrom/packrom: Command not found
make[1]: *** [Arkanoid.uze] Error 127
make: *** [demos/Arkanoid/default] Error 2
</code>

It's trying to call packrom from the tools directory,
but it's not there, because it's in the bin folder.
I then tried being clever and copying packrom and uzem to their respective 
directories in ./tools.
I also tried changing the Makefile of Arkanoid to have
PACKROM = ../../../bin/packrom .
Both of these actions resulted in 
<snip>
===================================
Building demo: demos/Arkanoid/default
===================================
make -C demos/Arkanoid/default 

avr-size: invalid option -- 'C'
Usage: avr-size [option(s)] [file(s)]
 Displays the sizes of sections inside binary files
 If no input file(s) are specified, a.out is assumed
 The options are:
  -A|-B     --format={sysv|berkeley}  Select output style (default is berkeley)
  -o|-d|-x  --radix={8|10|16}         Display numbers in octal, decimal or hex
  -t        --totals                  Display the total sizes (Berkeley only)
            --common                  Display total size for *COM* syms
            --target=<bfdname>        Set the binary file format
            @<file>                   Read options from <file>
  -h        --help                    Display this information
  -v        --version                 Display the program's version

avr-size: supported targets: elf32-avr elf32-little elf32-big srec symbolsrec 
verilog tekhex binary ihex
make[1]: *** [size] Error 1
make: *** [demos/Arkanoid/default] Error 2
<\snip>
when compiling 'make demos' or 'make'

Strangely enough, it did create an Arkanoid.hex file, and the game plays when I 
use '~/src/uzebox_src_3.1/bin/uzem ./Arkanoid.hex' when I am in the same folder 
as the .hex file.
What version of the product are you using? On what operating system?
uzebox_src_3.1.zip.
I am running Ubuntu Lucid Lynx 10.04, Linux kernel 2.6.32-32-generic .

Please provide any additional information below.
Although I am not entirely familiar with the build process used to create
these hex files, it appears to me as if the issue is that the proper tools are
not put in the proper place by the Makefile.

Original issue reported on code.google.com by decke...@gmail.com on 7 Jul 2011 at 2:12

@GoogleCodeExporter
Copy link
Author

This is a known issue on Linux. The standard binutils avr-size does not have 
the -C switch, it's a patch by WinAVR. I tough we had fixed that in the past to 
support both Windows and Linux. I use Windows and it works fine. A fix for this 
has been discussed on the forums, but I can't seem to find it. In the mean time 
try removing the -C switch?

Original comment by u...@belogic.com on 8 Jul 2011 at 1:48

  • Changed state: Accepted

@GoogleCodeExporter
Copy link
Author

I removed the -C switch from all the avr-size lines in the demos/defaults 
directory.
I also had to change the --mcu flag to --target ( hope this is right, just 
glanced over the man page). 

avr-size: unrecognized option '--mcu=atmega644'

changing --target to --mcu results in

avr-size: Arkanoid.elf: Invalid bfd target

Upon further review, it doesn't look like my version of avr-size supports 
specifying the microcontroller.
I'll take more of a look at it tomorrow.

Original comment by decke...@gmail.com on 8 Jul 2011 at 3:30

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

I'd check you have the latest setup for the AVR target. Those build script have 
been made and tuned by some Linux folks!

Original comment by u...@belogic.com on 8 Jul 2011 at 5:42

@GoogleCodeExporter
Copy link
Author

I might suggest instead trying svn trunk as it seems to have this fix already 
in. The mkdir bin; before running make is still required though. Also, it fails 
elsewhere for unrelated reasons. I'll be creating an issue with a patch for 
that (hopefully) sortly.

Original comment by losinggeneration on 8 Jul 2011 at 3:37

@GoogleCodeExporter
Copy link
Author

@losingge...@gmail.com,

Okay, I checked out revision 188 from the SVN trunk.

The mkdir bin problem has been solved already, apparently.

I did solve one build problem that I came across.
./demos/Mode9demo.c needs to be changed to ./demos/Mode9Demo.c ,
or else 'make' can't find it.

In the global Makefile I commented out line 44, which tried to make a 
Bootloader_Pragma, which doesn't have a folder.
I also commented out line 122, which prevented the copying of the *.uze files, 
since there really aren't any but one.

<code>
aaron@aaron-laptop:~/src/uzebox-read-only$ find -iname '*.uze'
./tools/packrom/Test/arkanoid.uze
</code>

It built after those three changes, and I've run a couple of the .hex files on 
the emulator,
so it looks like it (Revision 188) is working.

Original comment by decke...@gmail.com on 8 Jul 2011 at 8:51

@GoogleCodeExporter
Copy link
Author

"I also commented out line 122, which prevented the copying of the *.uze files, 
since there really aren't any but one."
Really? You should have one for pretty much each demos/*/default directory 
(except Bootloader I believe.) I'm guessing packrom isn't getting executed 
correctly by the Makefile(s).

Original comment by losinggeneration on 9 Jul 2011 at 1:28

@GoogleCodeExporter
Copy link
Author

"Really? You should have one for pretty much each demos/*/default directory 
(except Bootloader I believe.) I'm guessing packrom isn't getting executed 
correctly by the Makefile(s)."

You're right, the Makefile couldn't find packrom.
I added ./bin to my $PATH, and all of the *.uze files are now created and 
copied,
except for the "Bootloader" one, as you noted above.
Looks like everything compiles correctly now?

Is adding ./bin to the $PATH supposed to be part of the build process?

Original comment by decke...@gmail.com on 10 Jul 2011 at 2:40

@GoogleCodeExporter
Copy link
Author

"Is adding ./bin to the $PATH supposed to be part of the build process?"
Kind of, but mainly just because it assumes it's in the path. IMO, since it's 
in-tree, it should perhaps pass along something like UZEBIN_DIR=`pwd`/bin 
similar to how the tools get DEST_DIR passed to it. Then the tools would be 
called like this:
$(UZEBIN_DiR)packrom
That requires a minor change to each demo, but it should work fine.

Attached is the fix for that.

Original comment by losinggeneration on 10 Jul 2011 at 11:00

Attachments:

@GoogleCodeExporter
Copy link
Author

I just downloaded revision 188 into a clean directory,
and applied the patch from comment 9 of issue 11,
and the three patches from the original post of issue 12.

After the application of the patches, the software builds flawlessly.
Thank you for the patches, losingge...@gmail.com.

Original comment by decke...@gmail.com on 10 Jul 2011 at 4:47

@GoogleCodeExporter
Copy link
Author

losingge...@gmail.com, thanks for the patch in comment 9. Applied in r197.

Original comment by flavioza...@gmail.com on 9 Aug 2011 at 2:44

  • Changed state: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant