Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - pompeiisneaks

#51
I think the issue is with the 64 bit OS, but from what I understand, just adding -m32 to gcc cmdline args should help this, and it seems to be there in this case, but when I compile the modules, I get this type of error:

Question, some of the modules, raw_rec for example, fail to build with this error:

/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.4.7/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.4.7/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
make[3]: *** [raw2dng] Error 1

What am I missing?  Some .i686 rpm?

~Phil
#52
Question, some of the modules, raw_rec for example, fail to build with this error:

/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.4.7/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.4.7/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
make[3]: *** [raw2dng] Error 1

Is this because it wants a 32 bit gcc?  Can I not build some of these modules on a 64 bit os?

~Phil
#53
That was exactly what I needed, running it right now, seems great so far, focus peaking, exposure zebras, etc working.  I'm still pretty  new to ML so I'm playing around to see what I can do

~Phil
#54
Well I got that built just fine too, but looking at the makefile there should be a make fir to make the firmware but that doesn't seem to work, I've tried a few other make targets to no avail.  ugh, how do you create the firmware?

~Phil
#55
Oh ok, I'll use his repo, thanks,  What file is the .fir firmware file?  Is it the magiclantern.bin?

I tried looking around a while here on the site and didn't see it.
#56
I'm wanting to test it out, but I have two questions.

From that last link you gave it seems like they had a folder named .123, but they merged or renamed it to .113 and my latest pull from the mercurial repo didn't have a .123 dir.  I built the .113 dir just fine, but is that for the 1.2.3 firmware?  And second question, what of the built files is the .fir file is it the magiclantern.bin file?

Or what is the file I use to create the .fir file used in the normal installs?

~Phil
#57
Yup, thanks, I appreciate your help.

~Phil
#58
Well look at that, I can build 5D3 now on my fedora 19 laptop.  It fails with the 60D when I just try and build all, but success with my camera at any rate.  Oddly trying to build the arm toolkit from source fails due to texinfo 5.0 on fedora not being happy with the docs.  I did some reading on how to fix it on a linux from scratch thread but gave up after an hour of mucking about and not getting the right lines fixed.  (I have no idea how to fix texinfo files.)  At any rate, I'm down that road now, thanks!

~Phil
#59
Okay I'm pretty sure its just due to how old this machine's Fedora is.  I'll figure something else out.  Right now its failing to compile the docq target due to missing pandoc which isn't available in fedora until 18.  I'm on like 11 or 13, sorry its an old host I had sitting around as my router I figured I could dual purpose.  I'll give it a go on a more modern OS.

~Phil
#60
Sorry, everything I find on this forum about the Tiny C Compiler is not helpful, I tried disabling it and it still fails to build with this error:

[ CC       ]   menuindex.o
[ CC       ]   focus.o
[ CC       ]   notify_box.o
[ CC       ]   dialog_test.o
[ CC       ]   vram.o
[ CC       ]   aj_port.o
[ CC       ]   fps-engio.o
[ CC       ]   shoot.o
../../src/shoot.c:519:60: warning: initialization makes pointer from integer without a cast [enabled by default]
../../src/shoot.c:519:1: error: initializer element is not constant
../../src/shoot.c:521:53: warning: initialization makes pointer from integer without a cast [enabled by default]
../../src/shoot.c:521:1: error: initializer element is not constant
make[1]: *** [shoot.o] Error 1
make[1]: Leaving directory `/home/pdavis/src/magiclantern/magic-lantern/platform/5D3.113'
make: *** [5D3] Error 2


Why would the arm linker complaining about eabi mismatches have anything to do with the tiny c compiler?
#61
Not sure I follow.  I tried both the arm-elf-gcc and the arm-none-eabi-gcc and neither builds, both fail with similar errors.  Is it my os that's causing this?  Too old of libs or something?
#62
Nope that doesn't help either.  Same types of compile errors:

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:
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:

../../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/

#63
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.

#64
Quote from: 1% on November 07, 2013, 12:39:56 AM
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?
#65
Oh I should have included at the end of the error after many repeated lines of the VFP type errors, it ends with:

/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:

ld: error: Source object dietlibc.a(strrchr.o) has EABI version 5, but target magiclantern has EABI version 0
#66
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:

[ 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