RE: mxe-octave cross-build errors when building native-gcc

[John D]

-----Original Message-----
From: Philip Nienhuis [mailto:address@hidden 
Sent: Friday, March 07, 2014 11:03 AM
To: John D; address@hidden
Cc: 'John W. Eaton'
Subject: Re: mxe-octave cross-build errors when building native-gcc

John D wrote:
>
>
> -----Original Message-----
> From: Philip Nienhuis [mailto:address@hidden
> Sent: Friday, March 07, 2014 9:48 AM
> To: John D; address@hidden
> Cc: 'John W. Eaton'
> Subject: Re: mxe-octave cross-build errors when building native-gcc
>
> John D wrote:
>> -----Original Message-----
>> From: John D [mailto:address@hidden
>> Sent: Sunday, March 02, 2014 8:08 PM
>> To: address@hidden; Philip Nienhuis
>> Cc: John W. Eaton
>> Subject: mxe-octave cross-build errors when building native-gcc
>>
>> Message: 3
>> Date: Sun, 2 Mar 2014 14:41:30 -0800 (PST)
>> From: PhilipNienhuis <address@hidden>
>> To: address@hidden
>> Subject: mxe-octave cross-build errors when building native-gcc
>> Message-ID: <address@hidden>
>> Content-Type: text/plain; charset=UTF-8
>>
>> With mxe-octave
>>
>> (hg summary:
>> parent: 3556:22b42ac3fd68 tip
>>    native-gcc: remove unintended changes to native-gcc.mk from cs
>> b1ca68ddd02c)
>>
>> the cross-build consistently stops at native-gcc with (from the log):
>>
>> :
>> g++ -c   -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti
>>
> <snip>
>>
>> ----
>> I get the same trying to cross compile on my Fedora 20 machine, what 
>> OS are you using?
>> Attached patch makes it compile for me.
>> I looks to me that it is trying to pull in some system includes 
>> instead of the mxe build ones, but I couldn't get it to not do that 
>> except by compiling with mpc, mprf etc copied into the gcc build as 
>> per
> the patch.
>>
>> ---
>> With actual content in the patch (attached)
>
> Just found some time to try that patch. Result:
> native-gcc gets (cross-)built fine now, using mxe-octave's tip of 
> March 6 (today) - b1a7cff2d2a9 / Add octave forge of-netcdf package 
> (and support files).
>
> Thanks!
>
>   >
>   > The other thing needed (on my system as least) has been to copy 
> libgcc.a to  > the lib folder when making the dist (Not included in 
> this patch) in order  > for gcc to compile programs when installed.
>
> Could this be the reason for not being able to install packages as 
> reported e.g., here:
> http://octave.1599824.n4.nabble.com/cannot-install-packages-on-octave-
> 3-8-1r
> c3-tt4662113.html
> ?
> I did find a libgcc.a in ./lib/gcc/i686-w64-mingw32/4.8.2
>
> ==> Here I needed to copy libgcc_s.a from 
> .\lib\gcc\i686-w64-mingw32\lib\ (rather than libgcc.a
> from.\lib\gcc\o686-w64-mingw32\4.8.2\) to ./lib to avoid "cannot find 
> -lgcc_s" errors from ld.
> What needs to be patched for that? he nsis installer script?

<snip>

> ---
>
> Looks like the same issue - Probably binary dist rules.mk or 
> native-gcc.mk need to have the copy of the .a file added.
> Were you able to build native-gcc as is from mxe-octave? It wont build 
> for me on Fedora20 without the patch I sent out at the beginning of 
> the week. I am assuming everyone else isn't having that native-gcc  issue?

With your patch, native-gcc was built as-is. To be precise:
A "fresh" mxe-octave clone, that was in the state I left it last weekend (=
aborted native-gcc build stage), after updating and patching native-gcc.mk,
downloaded a few packages (netcdf, hdf5, etc), built them, built Octave and
then managed to build native-gcc + the installer.

I haven't seen native-gcc issue reports from other people building w
mxe-octave. According to the README on http://mxeoctave.osuv.de, Markus
seems to plan another one soon, maybe he'll hit it too.
Am I right that this native-gcc issue started after upgrading to
gcc-4.8.2 / mingw64?

My build system is Mageia-2 32 bit. One of these days I'll upgrade it to
Mageia-3 or 4 -64 bit (M-3 is fairly complete, but 4 still lacks many
required packages.)

Philip

---
I believe it was at that time - but is because the native gcc was changed
from building with gmp etc copied to the sources to building prior, rather
than the fact that it was a different version of gcc/mingw.