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.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks