Minimalist mSys/Mingw

[1%]

So i booted back into win7, yay, now my right hand doesn't burn anymore from the thinkpad GPU..

It was easy so far:
1. Install Mingw + Msys from the installer
2. Install python, add a copy named python2.exe
3. Add zip from http://gnuwin32.sourceforge.net/ and put it in c:\mingw\bin
4. Add paths for python, mingw, msys to windows paths
5. Download pre built arm toolchain and throw it in a path with no spaces
6. Set path in makefile.user

So now I can make -C and all that fun stuff... but what to do about truncate? its missing. I don't want to install bulky ass cygwin.

[Marsu42]

So now I can make -C and all that fun stuff... but what to do about truncate? its missing. I don't want to install bulky ass cygwin.

I was also using a manual msys/mingw setup for quite a while until I got fed up with the time consuming manual installation and quirks (gnuwin32 and msys' compiler is completely outdated so you cannot add anything that requires unix emulation, so for example you have to use cygwin truncate). Cygwin is even native x86_64 now!

One manual mingw problem is that unix devs hate Microsoft and make a point of not supporting mingw in their source and esp. autoconf configure even if there would be workarounds, and a lot of these patches are included in cygwin's mingw packages - basically you can use cygwin as an up-to-date msys and next to the build system like make just install the mingw-w64 packages for x64_x86 and i686 which doesn't add any bulk vs. msys at all.

Plus I realized that the auto-updater and installer of cygwin is too damn convenient to be ignored as all packages are up to date you don't have to painfully integrate and update native Windows versions of tex, subversion, git, python+packages, (...). Also nearly all mingw dev headers and dependencies you'll ever need are right there, and if you use native cygwin stuff the speed overhead vs. native Windows/mingw is much lower than I'd expected - the main lag is bacause Windows doesn't have fork() so for example running configure is much slower than on native Linux, but that's also the same on msys.

Btw if ever using cygwin, use this repo in addtion to the official redhead one and select the "exp" button in the installer to get the newest packages: http://cygwinports.org/ ... I invite every msys user to give it a go, you won't look back :-p

[1%]

Ok, guess I have to give it a go because now I get:

C:\Users\User\AppData\Local\Temp\ccMLQjc3.s: Assembler messages:
C:\Users\User\AppData\Local\Temp\ccMLQjc3.s:17: Error: misaligned branch destina
tion
make: *** [reboot.o] Error 1

for seemingly no reason at all.

I'm going out of state for a month and this is the only computer I'll have + either 6D or 7D or both. However many I can cram in my carryon. Need light room + compile without rebooting.

Heh, the binaries cywin makes for cr2hdr ,etc are much more bloaty.


If anyone wants to be a rebel:

truncate.exe (43 KB)
https://mega.co.nz/#!4lwDGDqJ!AZ1RLAcnVRxt3R-PSm9ZszlIdJw5jbBpeLa6VWEMyAw

x86_64 v of truncate. might need that cygwin abstraction dll.

[coderat]

I know it is is too late, but: as real Mingw-ist we add "translate" as shell script into \msys\bin. I do not know why you need "truncate", but several solutions possible:

1) use "copybytes" shell function to copy N bytes from one file to another:

#! /bin/sh
copybytes() { i=0; while IFS= read -rn 1 -d "\n" c;do [ "$c" ] &&echo -E -n "$c"||echo -n $'\015'; (( i++ )); if (( "$i"== $2 )) ; then break; fi; done < "$1" > "$3"; }
copybytes from.java 1234 to.java
mv to.java from.java

2) use head:

#! /bin/sh
head -c 1234 from.java > to.java
mv to.java from.java

etc.

Heh, the binaries cywin makes for cr2hdr ,etc are much more bloaty.

In fact both cygwin and mingw generate the same output code if compiler version matches. For some reason you may decide to build latest version of ARM cross compiler yourself, here is excellent howto: http://www.mingw.org/wiki/HostedCrossCompilerHOWTO

I use mingw for both ARM and FR80 without any side effects. Another reason to skip cygwin: cygwin actually put some settings in Windows registry, so you may long search for a bug...

Best regards,
coderat

[1%]

its funny that same source produces ~380kb binary for a1ex and like ~280kb binary for me... at first his was 300k and mine was 50K

[coderat]

Did you strip executables ?
For windows target:
strip -S --strip-unneeded /usr/local/fr30-elf/bin/*.exe

Regards,
coderat

[coderat]

Ok, guess I have to give it a go because now I get:

C:\Users\User\AppData\Local\Temp\ccMLQjc3.s: Assembler messages:
C:\Users\User\AppData\Local\Temp\ccMLQjc3.s:17: Error: misaligned branch destina
tion
make: *** [reboot.o] Error 1

No reason to giveup, let me try:
1) it hapens sporadic, each time on different file? Start "make" again and it works ?
2) if (1) may be try newer mingw compiler version. There was such problem in the past.
3) if it is always the same file, just post C:\Users\User\AppData\Local\Temp\ccMLQjc3.s for analyse. BTW you can generate with mingw gcc assembler output for any file by passing -S option.

Best regards,
coderat

[Marsu42]

In fact both cygwin and mingw generate the same output code if compiler version matches. For some reason you may decide to build latest version of ARM cross compiler yourself, here is excellent howto

I used to do that, compiling the latest Linaro on mingw x64 and use it with ML - take it from me: don't do it, it's not worth it because you'll run into more compiler problems than you could imagine and will wonder why your ML doesn't work while everybody else's does. Stick with the semi-"official" Linux/Win32 from Launchpad and enjoy photography rather than tracing compiler quirks.

[1%]

nope, didn't strip... but what worked for this is to just add truncate from cygwin

[coderat]

I used to do that, compiling the latest Linaro on mingw x64 and use it with ML - take it from me:

If you read my post, I am speaking about mingw for embedded as ARM, MIPS, FR80 RISC - absolutely no problems. Also Win32 I didn't have any problems.

rather than tracing compiler quirks.

Sorry, I am developing compilers, so not a problem for me.

@1%
Just in case you want to play: you can replace truncate with any scripts above, just need adjust filenames to be taken from arguments (usually usage truncate --size XX name)

Best regards,
coderat

[Marsu42]

Sorry, I am developing compilers, so not a problem for me.

Sorry if I misread your posts, my point was not to doubt your talent or experience, but to mention some ml features break under different compilers and there's no way to tell (well, for me) if for example auto-ettr doesn't work because I'm using it incorrectly, the feature is wip or the compiler broke it.

[thn-d]

So... did you fix the ccMLQjc3.s problems or is the mingw approach abandoned?

[dfort]

The last post on this topic was a long time ago but it might be worth a shot.

Directed to @coderat but if anyone has an answer please speak up.

Not sure if you're still interested in helping out with Magic Lantern issues but it seems that I'm very close to having a "real Mingw-ist" solution for compiling Magic Lantern. I'm not sure where I'm stuck but I believe that it might be the ARM cross compiler. What works on all the other platforms that I have tried is: https://launchpad.net/gcc-arm-embedded/4.8/4.8-2013-q4-major
The win32 version works fine under cygwin but when building in a MinGW/msys environment the compiled binary (autoexec.bin) does not work on the ARM device--in this case a Canon EOS-M camera.

In one of your posts (Re: Minimalist mSys/Mingw « Reply #3 on: December 09, 2013, 09:50:24 PM ») you stated that, "In fact both cygwin and mingw generate the same output code if compiler version matches" so am I to assume that it would be futile to try building an ARM cross compiler?

If the solution is to build a cross compiler that works in a Windows MinGW/msys environment, how would you do it? The source code for the 4.8-2013-q4-major version linked above has build instructions for Linux and Mac but not for Windows and the howto link in your post is very old: http://www.mingw.org/wiki/HostedCrossCompilerHOWTO

Hope you can enlighten me -- thanks!

[dfort]

By the way--if anybody wants to try again on a MinGW/msys Windows installation, I submitted a couple of pull requests that will allow you to build the command line tools (tested on mlv_dump, cr2hdr and raw2dng). It seems that this would be a great build environment for Windows users because it is rather simple to set up and the compiled command line tools don't need the cygwin .dll files--MinGW is using the native Windows libraries.

https://bitbucket.org/hudson/magic-lantern/pull-requests/656/modified-readme2modulestringspy-so-that-it/diff

https://bitbucket.org/hudson/magic-lantern/pull-requests/655/lv_rec-use-fseeko-fseeko64-depending-on/diff

Compiling for a camera platform will complete but the resulting autoexec.bin won't work. However, the modules do seem to work--I haven't done extensive tests on them yet but they build, load and appear to function properly.

So what is it with the autoexec.bin not working? The same Windows to ARM cross compiler works fine under cygwin. Is it something in the ML code?

[dfort]

Just a quick update, the autoexec.bin issue is solved with this pull request:

https://bitbucket.org/hudson/magic-lantern/pull-requests/658/build_tools-for-windows/diff

It was a problem with the Windows version of fopen needing the "-b" option when opening binary files.

http://magiclantern.fm/forum/index.php?topic=15845.msg154213#msg154213

If anyone is interested in how to set up a development environment with msys/MinGW:

http://magiclantern.fm/forum/index.php?topic=15845.msg154356#msg154356