Getting started with development

[stevefal]

Any idea why building is failing for me?

Makefile.user: http://popspring.com/mldrop/Makefile.txt

Output: http://popspring.com/mldrop/mlfail.txt

[Andy600]

After a few days of playing with cygwin I'm fairly comfortable with compiling.

I'm now getting started with mercurial so that I can keep up to date with @smeangol and make my own changes to the 50d build but I want to check if I have the correct mercurial workflow for Bitbucket in mind, so is this correct?:-

1) make my own fork of magic lantern on Bitbucket
2) clone magic lantern to my local drive
3) pull @smeangol's changes and merge with my local copy

If I change something (after thoroughly testing) where do I push it? back to magic lantern or smeangol

[AgentJJ]

Code: [Select]

../../picoc/library_ml.c: In function 'LibPress':
../../picoc/library_ml.c:132:14: error: 'BGMT_PRESS_FULLSHUTTER' undeclared (first use in this function)
../../picoc/library_ml.c:132:14: note: each undeclared identifier is reported only once for each function it appears in
../../picoc/library_ml.c: In function 'LibUnpress':
../../picoc/library_ml.c:158:14: error: 'BGMT_PRESS_FULLSHUTTER' undeclared (first use in this function)
In file included from ../../picoc/pico.c:13:0:
../../picoc/pico.c: In function 'PlatformExit':
../../picoc/platform_ml.c:62:1: warning: 'noreturn' function does return [enabled by default]
make: *** [pico.o] Error 1

This is the error I get in the latest 650D platform build with 4.7.3 prebuilt GCC ARM toolchain on Ubuntu 12.10.
It ('BGMT_PRESS_FULLSHUTTER') appears to be declared in the file.  Any thoughts?

[mkrjf]

Is there post outlining building on Mac?
I saw one post referencing yagarto toolchain - but link was to product not how to use.
Thx

[AndyPost]

For me as well.  Just bought spanking new MKIII.  Install is not working.  Mine came with the newest Firmware, 1.2.1.  Thought I'd try it.  It would claim that the firmware update was starting, the screen goes blank then the red light would just blink every so often. 

Also Tried backgrading to Firmware 1.1.3 and still no joy.  It claims the firmware update process is starting seems to do a quick card test, the red light blinks a few times then nothing.....

Any ideas would be greatly appreciated

[vicnaum]

How can I compile raw2dng.c?

Already downloaded cygwin, but makefiles under modules don't do anything, and raw2dng.c requires raw.h and chdk-dng.h

[a1ex]

make raw2dng.exe

[vicnaum]

Thanks! But what do you recommend to build it under windows?

There seems to be a problem with 'fseeko':

Cygwin gives me this:

$ make raw2dng
[ GCC      ]   raw2dng
[ GCC      ]   raw2dng
raw2dng.c: In function 'main':
raw2dng.c:60:5: warning: implicit declaration of function 'fseeko' [-Wimplicit-function-declaration]
[ GCC      ]   raw2dng
raw2dng.o:raw2dng.c:(.text.startup+0x58): undefined reference to `fseeko'
collect2: ld returned 1 exit status
Makefile:14: recipe for target `raw2dng' failed
make: *** [raw2dng] Error 1

MINGW this:

$ make raw2dng
[ GCC      ]   raw2dng
[ GCC      ]   raw2dng
raw2dng.c: In function 'main':
raw2dng.c:60:5: warning: implicit declaration of function 'fseeko' [-Wimplicit-function-declaration]
[ GCC      ]   raw2dng
raw2dng.o:raw2dng.c:(.text.startup+0x58): undefined reference to `fseeko'
collect2: ld returned 1 exit status
make: *** [raw2dng] Error 1

Google tells me that MinGW doesn't support big files (http://stackoverflow.com/questions/9026896/get-large-file-size-in-c)

What should I use to get it right?

[vicnaum]

Heh, installing all and everything from Devel in Cygwin (4Gb!) - did the trick

But anyway, it's interesting to know which cygwin module was required...

[John Kesl]

  almost there.

[John Kesl]

Hi,
I've got it figured out to some extent now. I'm running osx 10.7.5 and am only compiling. I am using yagarto. I've configured my makefile. and am trying to compile 7D. I get the following error. I  hg clone -r unified. and hg pull before make clean and then make 7D. (There was also an error for a missing menuindex file. I think menuindex.h, I corrected it by putting a menu index.h file so I think it's what is missing)

debug.o: In function `run_test':
debug.c:(.text+0xb9c): undefined reference to `edmac_memcpy_res_lock'
debug.c:(.text+0xbe0): undefined reference to `edmac_copy_rectangle_adv'
debug.c:(.text+0xc30): undefined reference to `edmac_copy_rectangle_adv'
debug.o: In function `mem_test_edmac_copy_rectangle':
debug.c:(.text+0xc94): undefined reference to `edmac_copy_rectangle_adv'
debug.o: In function `mem_benchmark_task':
debug.c:(.text+0x358c): undefined reference to `edmac_memcpy'
collect2: error: ld returned 1 exit status
make[1]: *** [magiclantern] Error 1
make: *** [7D] Error 2
Johns-Mac-Pro:magic-lantern johnkesl$

can anyone please help.

[John Kesl]

Hi,
I've got it figured out to some extent now. I'm running osx 10.7.5 and am only compiling. I am using yagarto. I've configured my makefile. and am trying to compile 7D. I get the following error. I  hg clone -r unified. and hg pull before make clean and then make 7D. (There was also an error for a missing menuindex file. I think menuindex.h, I corrected it by putting a menu index.h file so I think it's what is missing)

debug.o: In function `run_test':
debug.c:(.text+0xb9c): undefined reference to `edmac_memcpy_res_lock'
debug.c:(.text+0xbe0): undefined reference to `edmac_copy_rectangle_adv'
debug.c:(.text+0xc30): undefined reference to `edmac_copy_rectangle_adv'
debug.o: In function `mem_test_edmac_copy_rectangle':
debug.c:(.text+0xc94): undefined reference to `edmac_copy_rectangle_adv'
debug.o: In function `mem_benchmark_task':
debug.c:(.text+0x358c): undefined reference to `edmac_memcpy'
collect2: error: ld returned 1 exit status
make[1]: *** [magiclantern] Error 1
make: *** [7D] Error 2
Johns-Mac-Pro:magic-lantern johnkesl$

can anyone please help.

The answer is to insert edmac-memcpy.o to /src/Makefile.src in the following place (line 127)

ML_SRC_OBJS = \
 boot-hack.o \
 ico.o \
 edmac.o \
 menu.o \
 edmac-memcpy.o \
 debug.o \

I mustve been drunk

[Marsu42]

Concerning Windows compilation w/o a vm under cygwin or msys/mingw:

I see there are tutorials for setting up a vm and even a link to a pre-built vm, but imho this really isn't necessary since ml compiles under plain windows just fine and there is no noticeable speed degradation since ml is such a small project.

Would it make sense to make a pre-built cygwin environment available with a compilation script, pre-set Makefile.user and such & shortcut to a script that pulls the ml source (updates), runs make & drops the autoexec.bin & modules somewhere? This would be a "one click" windows solution for people who want to do minor changes to the trunk source and don't have the time or experience or set up the compilation environment for themselves.

I don't know if the nightly buiild script can/should be used for this since it's really just hg pull & make ... anyone interested in this, any objections to the idea?

[primeone]

Speaking as someone who's just wrestled with Cygwin and compiling ML, I vote yes

[primeone]

If it's still relevant : I fixed this exact build problem by upgrading to the 4.7.4 version.

http://www.magiclantern.fm/forum/index.php?topic=2899.msg69446#msg69446

[Marsu42]

Here's a reference what int types to use, I'll cross-reference it here so it's easier to find:

http://www.magiclantern.fm/forum/index.php?topic=7122.msg83922#msg83922

https://bitbucket.org/hudson/magic-lantern/commits/f2660b2263c4ad7129e2f622056d924db6565cbb

Quote from g3gg0:

in general i say:

use uint32_t everywhere.

in cases you need signed integers, use int32_t.

dont use uint16_t or uint8_t for arithmetics, just for constructing structs. reason: compilers often add code after every arithmetic instruction to variables of this type to ensure the result is 0x00-0xFF only this will slow down code for no reason.

if you just have a iterating loop, your counter can be int of course. (a la: "i dont care about its width, 16 bit is enough")

if uint32_t isnt enough for your arithmetics, choose 64 bit of course

remember:

in C you get only the guarantee that char is 1 bits or more (no typo!)

short is 16 bits or more, but at least the same width as char.

int is 16 bit or more, but at least the same width as short

long is 32 bit or more, but at ... as int

long long is 64 bi.... and so on

[g3gg0]

see http://en.wikipedia.org/wiki/C_data_types
there you see the type widths that C compilers guarantee.

[Marsu42]

see http://en.wikipedia.org/wiki/C_data_types there you see the type widths that C compilers guarantee.

For ml code on the camera - does it make any sense at all trying to reduce the memory used by going for smaller data types, or is this absolutely negligible vs. the camera's memory and general ml memory overhead? Is this tradeoff the reason why you suggested simply using uint32_t unless used in structs that are duplicated a lot?

[pompeiisneaks]

Question on my failed build, if someone can make sense of this.  I did the summon-arm and its TARGET=arm-elf but when I tried to compile first time, the ARM_ABI=none-eabi

instead I changed it to match my elf setup:

ARM_ABI=elf.

In the howto docs it does somewhat contradict.  It talks about none-eabi and elf both.  this is from: http://magiclantern.wikia.com/wiki/Build_instructions/Unified

Example, early on, after summon-arm it says:

This will install arm-elf-gcc under ~/arm-toolchain462/bin.

Okay, elf-gcc.

I even tested the .c file and got a .o that with 'file' showed it was arm executable. 

Later, though it talks about:

If you are using the official ARM toolchain in the same file also set ARM_ABI=none-eabi and ARM_PATH as appropriate.

which is it, none-eabi or elf?  If I do elf it starts compiling, if I leave it at none-eabi it won't run because the arm compiler doesn't have a file named arm-eabi* at all.   (this may just be a red herring, but trying to understand.)

but then when I compile the source, using elf not none-eabi, it runs for a while and errors out:

Code: [Select]

[ VERSION  ]   ../../platform/60D.111/version.bin
[ VERSION  ]   ../../platform/60D.111/version.c
[ CC       ]   version.o
make -C ../../tcc
make[2]: Entering directory `/home/pdavis/src/magiclantern/magic-lantern/tcc'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/pdavis/src/magiclantern/magic-lantern/tcc'
[ LD       ]   magiclantern
/home/pdavis/arm-toolchain462/lib/gcc/arm-elf/4.6.2/../../../../arm-elf/bin/ld: error: version.o uses VFP instructions, whereas magiclantern does not

so I'm confused.  What could I be doing wrong?  Or is there some new error in the recent commits to the tree? 

Any help would be greatly appreciated.  Also I'm on a fedora linux build and I installed the required deps listed, but I still ended up having to install the following RPM's:

gcc
patch
texinfo

another note is when installing the perl modules on redhat you don't need to use CPAN for most.  I was able to install File::Slurp with:

yum install perl-File-Slurp. Those things could help clarify a bit on the redhat/fedora build processes.  (maybe its assumed that if I'm building anything, I'd already have gcc, patch and texinfo, but just in case)

I am on an older fedora, 11 I think, that may be part of the issue?  The gcc I have locally is 4.4.1 but the one used by the arm toolchain seems to be 4.6.2. 

~Phil 

[pompeiisneaks]

Oh I should have included at the end of the error after many repeated lines of the VFP type errors, it ends with:

Code: [Select]

/home/pdavis/arm-toolchain462/lib/gcc/arm-elf/4.6.2/../../../../arm-elf/bin/ld: failed to merge target specific data of file newlib-libc.a(lib_a-memset.o)
boot-hack.o: In function `my_assert_handler':
boot-hack.c:(.text+0x48): relocation truncated to fit: R_ARM_PC24 against symbol `get_current_task' defined in *ABS* section in magiclantern
boot-hack.o: In function `my_init_task':
boot-hack.c:(.text+0xd8): relocation truncated to fit: R_ARM_PC24 against symbol `get_current_task' defined in *ABS* section in magiclantern
boot-hack.c:(.text+0x144): relocation truncated to fit: R_ARM_PC24 against symbol `init_task' defined in *ABS* section in magiclantern
boot-hack.c:(.text+0x1f4): relocation truncated to fit: R_ARM_PC24 against symbol `msleep' defined in *ABS* section in magiclantern
boot-hack.c:(.text+0x21c): relocation truncated to fit: R_ARM_PC24 against symbol `msleep' defined in *ABS* section in magiclantern
boot-hack.c:(.text+0x22c): relocation truncated to fit: R_ARM_PC24 against symbol `msleep' defined in *ABS* section in magiclantern
boot-hack.c:(.text+0x26c): relocation truncated to fit: R_ARM_PC24 against symbol `msleep' defined in *ABS* section in magiclantern
boot-hack.c:(.text+0x2e0): relocation truncated to fit: R_ARM_PC24 against symbol `task_create' defined in *ABS* section in magiclantern
boot-hack.o: In function `my_big_init_task':
boot-hack.c:(.text+0x338): relocation truncated to fit: R_ARM_PC24 against symbol `call' defined in *ABS* section in magiclantern
boot-hack.c:(.text+0x370): relocation truncated to fit: R_ARM_PC24 against symbol `msleep' defined in *ABS* section in magiclantern
boot-hack.c:(.text+0x38c): additional relocation overflows omitted from the output
collect2: ld returned 1 exit status

There were also some errors like so:

Code: [Select]

ld: error: Source object dietlibc.a(strrchr.o) has EABI version 5, but target magiclantern has EABI version 0

[1%]

why not run the launchpad pre-built compiler? you just extract it and add the path to makefile.user

[pompeiisneaks]

why not run the launchpad pre-built compiler? you just extract it and add the path to makefile.user

because I'm following the wiki on how to build it and nowhere did it mention a launchpad pre-built compiler or how to get it.  Do you have a reference on the wiki to that somewhere?

[pompeiisneaks]

Oh I see it in the first post, I was following the third method of compiling it. I'll give the prebuilt one a try.

[pompeiisneaks]

Nope that doesn't help either.  Same types of compile errors:

Code: [Select]

ld: error: Source object ../../platform/60D.111/stubs.o has EABI version 5, but target magiclantern has EABI version 0
but it seems to happen in a different place.  Right before the errors:

Code: [Select]

CC       ]   edmac-memcpy.o
[ AR       ]   strrchr.o
[ AR       ]   dietlibc.a
[ AR       ]   lib_a-setjmp.o
[ AR       ]   newlib-libc.a
[ LD       ]   magiclantern
and then just after a ton of those EABI version 5 vs 0 errors:

Code: [Select]

../../tcc/libtccx.o: In function `strcat_printf':
arm-gen.c:(.text+0xfc): relocation truncated to fit: R_ARM_PC24 against symbol `vsnprintf' defined in *ABS* section in magiclantern
../../tcc/libtccx.o: In function `error1':
arm-gen.c:(.text+0x2d8): relocation truncated to fit: R_ARM_PC24 against symbol `vsnprintf' defined in *ABS* section in magiclantern
collect2: error: ld returned 1 exit status
make[1]: *** [magiclantern] Error 1
make[1]: Leaving directory `/home/pdavis/src/magiclantern/magic-lantern/platform/60D.111'
make: *** [60D] Error 2

No love.  This is just pulled from recent mercury via: hg clone -r unified https://bitbucket.org/hudson/magic-lantern/

[1%]

You changed the eabi back?