#16 default to lib32/lib64 as appropriate

closed-fixed
CRT (12)
5
2009-09-26
2009-07-11
Mook
No

Attached patch will default to --enable-lib32 on i*86 and --enable-lib64 on x86_64, with the ability to override.

I'm getting tired of specifying --enable-lib32 --disable-lib64 manually, and this will help me clean up buildbot ;)

Discussion

1 2 > >> (Page 1 of 2)
  • Ozkan Sezer

    Ozkan Sezer - 2009-07-12

    With --host=x86_64-pc-mingw32 --enable-lib32, this gives the final report of
    configure: WinCE runtime.....: no
    configure: Win32 runtime.....: yes
    configure: Win64 runtime.....: yes
    is this what you intended?

     
  • NightStrike

    NightStrike - 2009-07-12

    To do this right, there's more that has to change. First, to follow autotools conventions, the logic should be AS_CASE'd in the "action-if-given" path of each enable option. Second, all of the compile flags need to be rethought in terms of whether to pass -m32 or -m64 to the various libraries based on which compiler is used as default. If the compiler's primary target is win32, then -m64 is needed on each 64-bit lib and nothing on the 32-bit libs. If the primary target is win64, then -m32 is needed for 32-bit and nothing for 64-bit. Currently, everything is very "win64 primary" focused. I have some local patches where I was trying to tackle all of these issues in a not-ugly-ified way.

     
  • Ozkan Sezer

    Ozkan Sezer - 2009-07-12

    and not enable both w32 and w64 targets at the same time.

     
  • Mook

    Mook - 2009-07-13

    --host=x86_64-pc-mingw32 --enable-lib32 giving both was what I intended, though whether that behaviour is sane is open to discussion :) (--disable-lib?? will turn things off explicitly, of course)

    Will attach a patch later, need to go read autoconf manual more.

    Would just passing in -m32 / -m64 all the time, even for non-multilib toolchains, work?

     
  • Mook

    Mook - 2009-07-15

    add -m64, arm defaults to wince

     
  • Mook

    Mook - 2009-07-15

    oops, didn't mean to delete.

    anyway, the new patch adds -m64 to win64 (having superfluous -m32/-m64 is fine, as long as binutils can deal with the right target).

    also added --enable-libce as a defauilt for arm hosts at jon_y's request.

     
  • Ozkan Sezer

    Ozkan Sezer - 2009-07-15

    Since you specifically intend on enabling multiple targets, would it be too much of a hassle to detect the multilib capabilities of the hosted gcc and binutils?

     
  • NightStrike

    NightStrike - 2009-07-15

    This is where things start to get ugly now. You'd need to edit the CFLAGS of every lib primary. I have been asking for an automake feature to allow per-directory configurations, but they haven't been able to do it yet. For instance, being able to say lib64_CFLAGS. You can't stick it in AM_CFLAGS, and you can't reset that variable mid-Makefile. So, it becomes a little ugly to maintain.

     
  • Mook

    Mook - 2009-07-19

    add -m64 all over the plce, fix libce warning

     
  • Mook

    Mook - 2009-07-19

    Eww, can't do anything smart with automake at all :)

    will try to get this checked in first, while I think about detecting multilibness checks...

     
  • Mook

    Mook - 2009-07-19

    check for ability to compile 32/64 instead of using host cpu

     
  • NightStrike

    NightStrike - 2009-08-18

    Please commit the logic cleanup of the libce/lib32/lib64 checking separately.

     
  • NightStrike

    NightStrike - 2009-08-18

    + AC_LINK_IFELSE(
    Can you use COMPILE instead of LINK?

    + [enable_lib64=yes
    + AC_MSG_RESULT([yes])],
    + [enable_lib64=no
    + AC_MSG_RESULT([no])])

    Can you combine this into one?
    [enable_lib64=yes],
    [enable_lib64=no])])])])])])])])])])])
    AC_MSG_RESULT([$enable_lib64])

     
  • Mook

    Mook - 2009-09-04

    added new patch to address comments + update to trunk; sorry for the delay.

    bzipped because sf doesn't take attachments that large, and configure changes... a lot.

     
  • NightStrike

    NightStrike - 2009-09-09

    With the current patch, everything seems to be fine, with one exception:

    During review, Mook found a quoting mistake for the two lines that restore CFLAGS in configure.ac. Other than that, the attached patches look good.

    It wouldn't be a bad idea to run a few "make distcheck"'s before commit (or soon after).

    Patch set to Accepted with the above change. Please commit.

     
  • NightStrike

    NightStrike - 2009-09-09
    • status: open --> open-accepted
     
  • Mook

    Mook - 2009-09-09

    Trying to run make distcheck...

    (first, at the bottom of Makefile.am, testcases/t_wreadir needs an extra d)

    /bin/sh ./libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -pipe -std=gnu99 -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes -g -O2 -o testcases/tstmainc testcases/tstmainc.o
    libtool: link: x86_64-w64-mingw32-gcc -pipe -std=gnu99 -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes -g -O2 -o testcases/.libs/tstmainc testcases/tstmainc.o
    /mnt/data/src/mingw-w64/sources/build/root/lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/bin/ld: crt2.o: No such file: No such file or directory
    collect2: ld returned 1 exit status
    make[3]: *** [testcases/tstmainc] Error 1
    make[3]: Leaving directory `/mnt/data/src/mingw-w64/sources/build/mingw/mingw-w64-crt/mingw-w64-runtime-1.0b/_build'
    make[2]: *** [check-am] Error 2
    make[2]: Leaving directory `/mnt/data/src/mingw-w64/sources/build/mingw/mingw-w64-crt/mingw-w64-runtime-1.0b/_build'
    make[1]: *** [check] Error 2
    make[1]: Leaving directory `/mnt/data/src/mingw-w64/sources/build/mingw/mingw-w64-crt/mingw-w64-runtime-1.0b/_build'
    make: *** [distcheck] Error 1

    > find mingw-w64-runtime-1.0b/_build/ -iname 'crt2.o'
    mingw-w64-runtime-1.0b/_build/lib64/crt2.o

    Sigh, I guess I just don't get to check in ;)

     
  • Ozkan Sezer

    Ozkan Sezer - 2009-09-20

    > I'm getting tired of specifying --enable-lib32 --disable-lib64 manually,

    With this patch in, I have to manually do --disable-lib32 --enable-lib64 on i686-linux ;)
    No big deal, though..

     
  • Mook

    Mook - 2009-09-23

    Eh, you should just need --disable-lib32 (assuming you are using a multilib compiler/binutils and only want lib64). If you are using a toolchain that only targets lib64, but get lib32 on and lib64 off by default, please poke me (on IRC or here)!

    The CRT is being built with the bootstrap cross-compiler, right? :)

    Checked in as r1349

     
  • Mook

    Mook - 2009-09-23
    • status: open-accepted --> closed-fixed
     
  • Ozkan Sezer

    Ozkan Sezer - 2009-09-23

    I can't access my 32 bit linux machine immediately right now, but yes:
    - I am using x86-linux - to - x64_64-pc-mingw32 toolchain
    - I only want "lib64"
    - I am _not_ using multilib: (Tried it very briefly , not impressed with it)
    - Running on x86-linux, I get lib32 only without explicit switches to configure.

    Not nice considering our major objective is x86_64. Can be easily
    worked around by --disable-lib32 --enable-lib64.

     
  • Mook

    Mook - 2009-09-23

    Darn, reopening while I look at it to make sure I didn't break things. That certainly doesn't sound right

     
  • Mook

    Mook - 2009-09-23
    • status: closed-fixed --> open-accepted
     
  • Mook

    Mook - 2009-09-26

    ... Or it works again. meh.

     
1 2 > >> (Page 1 of 2)

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

Sign up for the SourceForge newsletter:





No, thanks