You just want not to use " --enable-multiarch​".


Thanks,

Andrew Pinski

From: linaro-toolchain-bounces@lists.linaro.org <linaro-toolchain-bounces@lists.linaro.org> on behalf of Diane Holt <holt.diane@gmail.com>
Sent: Wednesday, March 05, 2014 2:33 PM
To: Zhenqiang Chen
Cc: Linaro Toolchain
Subject: Re: Building 4.8 without multilib
 
On the other hand, disabling multilib didn't accomplish what I wanted. What I want is for things to be where they used to be, with regard to /lib, /usr/lib, /usr/include, and include/C++ -- I don't want that extra arm-linux-gnueabi subdir under those. Granted, I can re-organize things once I've got the toolchain built, but it would be nice not to have to go through all that, since it's a bit of a pain to do (it's not just moving files, but re-doing symlinks as well). That's what I hoped --disable-multilib would do -- keep things simple and not create those extra subdirs. Is there no way now to not have that happen?

Thanks,
Diane


On Wed, Mar 5, 2014 at 2:21 PM, Diane Holt <holt.diane@gmail.com> wrote:
I don't build eglibc -- I use a prebuilt one. But that does look to have been the issue. The one I used before was 2.12.1, so I tried a later one (2.15) and things worked.

Thanks very much,
Diane


On Tue, Mar 4, 2014 at 10:09 PM, Zhenqiang Chen <zhenqiang.chen@linaro.org> wrote:
How do you build your eglibc/glibc?

Can you share your gcc config for me to reproduce it?

Thanks!
-Zhenqiang

On 5 March 2014 10:49, Diane Holt <holt.diane@gmail.com> wrote:
> Sorry, but I'm not sure I understand either of these replies. I'm trying to
> find a way to be able to build with --disable-multilib. When I build with
> multilib enabled, it succeeds just fine.
>
> Thanks,
> Diane
>
>
> On Tue, Mar 4, 2014 at 6:37 PM, Ryan Arnold <ryan.arnold@linaro.org> wrote:
>>
>> On Wed, Mar 5, 2014 at 8:01 AM, Diane Holt <holt.diane@gmail.com> wrote:
>> > Is that supposed to be possible? When I add --disable-multilib to the
>> > configure options, the build fails on the install, because it hasn't
>> > built
>> > any of src/gcc-linaro-4.8-2014.02/libgcc:
>> >
>> > /bin/sh ../../../../src/gcc-linaro-4.8-2014.02/libgcc/../mkinstalldirs
>> >
>> > /home/ubuntu/work483/build/sysroot/home/ubuntu/opt/cross-gcc-linaro/lib/gcc/arm-linux-gnueabi/4.8.3
>> > /usr/bin/install -c -m 644 libgcc_eh.a
>> >
>> > /home/ubuntu/work483/build/sysroot/home/ubuntu/opt/cross-gcc-linaro/lib/gcc/arm-linux-gnueabi/4.8.3/
>> > /usr/bin/install: cannot stat `libgcc_eh.a': No such file or directory
>> > make[3]: *** [install-shared] Error 1
>> > make[3]: Leaving directory
>> > `/home/ubuntu/work483/build/gcc/arm-linux-gnueabi/libgcc'
>> > make[2]: *** [install-target-libgcc] Error 2
>> > make[2]: Leaving directory `/home/ubuntu/work483/build/gcc'
>> > make[1]: *** [install] Error 2
>> > make[1]: Leaving directory `/home/ubuntu/work483/build/gcc'
>> > make: *** [stamp/gcc-install] Error 2
>> >
>> > I don't want or need multilib, so I'd rather build the toolchain without
>> > it,
>> > but before I try to make that happen, I wanted to make sure it's
>> > supposed to
>> > be able to get built correctly that way.
>> >
>> > Thanks,
>> > Diane
>>
>> Diane,
>>
>> I ran into this issue as well, and believe that it's related to your
>> sysroot lacking the proper soft-float headers and/or missing kernel
>> headers.
>>
>> This means that your sysroots include/ directory needs to be prepared
>> for multi-lib headers before you do a multi-lib enabled gcc build.
>>
>> So, what I did was identify the multi-lib configurations that are
>> enabled when I selected a particular --target.
>>
>> Take that information and build the kernel headers for all
>> configurations and install those headers into the sysroot include
>> directory.
>>
>> Then build a glibc version for each configuration and install the
>> headers into the sysroot.
>>
>> Then you might need to inform GCC where the include directories are
>> (though a properly formatted multi-lib sysroot should be automatically
>> detected when you pass the sysroot switch).
>>
>> Zhenqiang Chen knows about this process a bit better than I do.
>>
>> --
>> Ryan S. Arnold
>> Linaro Toolchain Working Group
>> www.linaro.org
>
>