ada multilib i686 version

  • Doug Semler

    Doug Semler - 2010-04-11

    Noticed something playing around with multilib building a x86 compiler with 64 bit as multilib: the for libada can't handle this case.

    Is it worth opening anything on the gcc side or will it shrugged off due to the target status?  (basically, the gcc-interface/ada/ needs an extra switch around 1645 where it selects the 64 bit ads on the 32 bit side if it's a multilib, something like

           LIBGNAT_TARGET_PAIRS += \
    -      LIBGNAT_TARGET_PAIRS += \
    +      ifeq ($(strip $(MULTISUBDIR)),/64)
    +        LIBGNAT_TARGET_PAIRS += \
    +      else
    +        LIBGNAT_TARGET_PAIRS += \
    +      endif


  • NightStrike

    NightStrike - 2010-04-12

    Stage 1, which GCC is in right now, is the perfect time for this kind of thing.  Definitely open it as a GCC bug and ping it to death :)

  • Doug Semler

    Doug Semler - 2010-04-12

    Ok, will do that when I get a chance (later today), because I'm doing a bunch of tests on the target library installations and want to also open one with respect to that (and at least be semi-intelligent about it :)) since the installation directories are woefully incorrect…

    BTW, I don't agree with the patch that fixes it by patching the libtool stuff…which would have to go upstream to libtool anyway and seems messy…I personally believe that the directory passed to the -bindir flag is incorrect in the target library build makefiles.  In addition, the shared libgcc is wrong for linux as well as mingw when enable-version-specific is used, so there is a different underlying issue there, aside from using bindir instead of slibdir.


Log in to post a comment.

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

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks