mingw-w64-crt/Makefile.am, r5197 and r5199

2012-07-12
2013-06-06
  • Scott Michel
    Scott Michel
    2012-07-12

    NightStrike:

    I suspect strongly that you significantly broke the cross-compile instructions in those changes because when -prefix and -with-sysroot are set, the continued gcc compile will now break (headers, libraries are not installed under the $(host) subdirectory, as they ought.)

    My mingw-w64 CRT configuration line looks like:

    ../../mingw-w64/configure -host=x86_64-w64-mingw32 \
    -enable-lib32 \
    -enable-lib64 \
    -with-sysroot=${thePrefix} \
    -prefix=${thePrefix}

    The next effect of which is to install the 64-bit libraries under ${thePrefix}/lib, 32-bit libraries under ${thePrefix}/lib32 and headers under ${thePrefix}/include. Naturally, this breaks the continued build of gcc later on, because xgcc (collect2's invocation of ld) expects to find stuff under the ${thePrefix}/mingw/ or ${thePrefix}/x86_64-w64-mingw32 hierarchies.

    I can get around the include hiearchy not being in the right place by inserting a junction point on my NTFS file system. Not a big deal.

    Libraries, OTOH, are a bigger deal because (a) binutils previously installed the linker's ldscript directory , (b) ranlib needs to be run following an archive copy. So, a junction point would not be solution.

    Prior to r5197 and r5199, the cross-compile build process worked rather nicely.

    Note: I'm building this on MSys under Win7.

     
  • Scott Michel
    Scott Michel
    2012-07-12

    Unless, the suggested fix is to have ${thePrefix}/mingw and ${thePrefix}/x86_64-w64-mingw32 point back to their parent directory, ${thePrefix}, which seems totally FUBAR.

     
  • rubenvb
    rubenvb
    2012-07-12

    I think what you're expected to do is configure mingw-w64 with

    --prefix=$PREFIX/$TARGET
    

    And leave everything else (GCC etc.) as it was. Note that I haven't
    tested this myself, but I see no reason for this not to work.

     
  • Scott Michel
    Scott Michel
    2012-07-13

    Nice update to the build notes. :-)

    Violates the principle of least surprise in a big way.

     
  • Ozkan Sezer
    Ozkan Sezer
    2012-07-13

    which seems totally FUBAR.
    Violates the principle of least surprise in a big way.

    Agreed wholeheartedly.

     
  • Scott Michel
    Scott Michel
    2012-07-13

    rubenvb: No, setting prefix via your suggestion breaks things worse. If sysroot is also set, the header install phase expects to find the newly installed headers under $PREFIX/include (the sysroot) and not under $PREFIX/include.

    I did try making junction points for $PREFIX/mingw and $PREFIX/x86_64-w64-mingw32 point back to their parent directory, $PREFIX. This approach works, but comes with the nasty side effect of an infinite junction/symlink dereference loop, if some reason, one decides the execute the explorer's search or Unix find command.