glibc 2.16.0

glibc 2.16.0

[白い熊]

I'd like to build my arm crosscompile toolchain with glibc 2.16.0. I
understand ct-ng doesn't support glibc 2.16.0, I could swear though
that when originally researching how to use ct-ng, I've stumbled on a
page where the author explained how to add other versions of tools,
like other versions of gmp, etc. to ct-ng, consisting of editing some
conf files in ct-ng's directory or something. However, search as I
might, I can't locate that page.

Can I add glibc 2.16.0 to the menuconfig options when configuring the
toolchain somehow, so that I could try building with it?

If not, can I compile glibc 2.16.0 with the glibc 2.14.1 toolchain,
and then move it to ~/x-tools to use this version when crosscompiling
other software? I seem to have also seen some discussion on this, but
also can't find it.

Thanks for any help.
-- 
白い熊

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: glibc 2.16.0

[Bernhard Walle]

Hi,

* 白い熊 <ShiroiKuma@ShiroiKuma.org> [2012-12-16 18:15]:
> I'd like to build my arm crosscompile toolchain with glibc 2.16.0. I
> understand ct-ng doesn't support glibc 2.16.0, I could swear though
> that when originally researching how to use ct-ng, I've stumbled on a
> page where the author explained how to add other versions of tools,
> like other versions of gmp, etc. to ct-ng, consisting of editing some
> conf files in ct-ng's directory or something. However, search as I
> might, I can't locate that page.

Use

  %  ./scripts/addToolVersion.sh --glibc -s -c 2.16.0

after "make" and before "make install". Or just edit onfig/libc/glibc.in
manually...


Regards,
Bernhard

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: glibc 2.16.0

[白い熊]

On Sun, Dec 16, 2012 at 9:22 PM, Bernhard Walle <bernhard@bwalle.de> wrote:
> after "make" and before "make install". Or just edit onfig/libc/glibc.in
> manually...

Thanks for the how-to. I edited the config/libc/glibc.in and
recompiled the toolchaing with glibc-2.16.0... So far so good.

Now, however I need serious help, since I can't solve the following issue.

I've built glibc-2.16.0 with it and compiled a host of GNU apps, for
instance tar. I'm doing this for an Android phone, so I get full glibc
and GNU utilities natively on it. Using the GNU tools then is as
simple as bindmounting glibc-2.16.1/lib to /lib and exporting
LD_LIBRARY_PATH=/path/to/gcc-4.7.2/lib

Now, the big question: For instance the tar binary I've compiled with
it doesn't run, gives me:
/system/bin/sh: ./tar: No such file or directory

which on Android signifies, the glibc is not present.

However, if I bindmount the glibc-2.14.1 to /lib, the glibc-2.14.1
being the glibc that I've crosscompiled before this with a
glibc-2.14.1 toolchain, the tar runs.

Leading me to believe the tar is built against glibc-2.14.1

But how can this be?

If I check ~/x-tools/arm-exynos-linux-gnueabi/arm-exynos-linux-gnueabi/sysroot/lib
it has ld-2.16.so libc-2.16.so and so on?

So how come the binaries run against a 2.14.1 glibc but not against a
2.16.0? I'm cracking my brains here, I'm sure there's a simple
oversight somewhere on my part, but can't figure it out.

Any ideas would be much appreciated. Many thanks in advance
-- 
白い熊

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: glibc 2.16.0

[Bernhard Walle]

Hi,

* 白い熊 <ShiroiKuma@ShiroiKuma.org> [2012-12-17 20:25]:
> 
> But how can this be?

The binaries have /lib/ld-linux.so.2 as interpreter (run "readelf -l"
and see the INTERP header) set. So if the kernel executes the binary,
they're executed with /lib/ld-linux.so.2 and that's from android libc
(which is not glibc).

You can change the interpreter when compiling with

    gcc ... -Wl,-dynamic-linker,/my/lib/ld-linux.so.2 ...

or patch it afterwards with patchelf from http://nixos.org/patchelf.html.

I think that would be the (first?) step to use your own libc, but I'm
far away from being an expert in that area...


Regards,
Bernhard

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Fwd: glibc 2.16.0

[白い熊]

On Tue, Dec 18, 2012 at 12:10 AM, Bernhard Walle <bernhard@bwalle.de> wrote:
>
> The binaries have /lib/ld-linux.so.2 as interpreter (run "readelf -l"
> and see the INTERP header) set. So if the kernel executes the binary,
> they're executed with /lib/ld-linux.so.2 and that's from android libc
> (which is not glibc).

Yes, this is true, I'm aware of that. However I bindmount glibc's lib
directory to /lib, thereby glibc is used and not android libc.

So what beats me is, if I bindmount the glibc 2.14.1's lib to /lib,
the crosscompiled binaries run, for instance tar produces the desired
output. However it shouldn't, because I was crosscompiling it against
2.16.0.

Even more problemact, if I bindmount the glibc 2.16.0's lib to /lib,
the crosscompiled binaries don't run, and I get the mentioned
'/system/bin/sh: ./tar: No such file or directory' error...

But how can this be?
--
白い熊

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: glibc 2.16.0

[白い熊]

On Tue, Dec 18, 2012 at 12:10 AM, Bernhard Walle <bernhard@bwalle.de> wrote:

> The binaries have /lib/ld-linux.so.2 as interpreter (run "readelf -l"

I've got it thanks to you. It got me thinking, I went double checking
and sure enough:

in the crosscompiled glibc-2.14.1's lib there is ld-linux.so.3, which
is good. In the 2.16.0's there is ld-linux-armhf.so.3

So it doesn't find ld-linux.so.3 it's looking for... Why does the
crosscompiler append the -armhf in the 2.16.0's case? Where can I set
the behavior? I mean, would like to know, I can solve the issue for
now via symlinking, but still...

> You can change the interpreter when compiling with
>
>     gcc ... -Wl,-dynamic-linker,/my/lib/ld-linux.so.2 ...

Yeah, I'll probably look into this, as a way to remove the necessity
to bindmount /lib, thanks for the hint...
-- 
白い熊

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: glibc 2.16.0

[白い熊]

On Tue, Dec 18, 2012 at 12:37 AM, 白い熊 <ShiroiKuma@shiroikuma.org> wrote:
>> You can change the interpreter when compiling with
>>
>>     gcc ... -Wl,-dynamic-linker,/my/lib/ld-linux.so.2 ...
>
> Yeah, I'll probably look into this, as a way to remove the necessity
> to bindmount /lib, thanks for the hint...

And a followup question to this:

Looking for instance at ldd of the tar binary, it links to:
        librt.so.1 => /lib/librt.so.1 (0xdeadbeef)
        libc.so.6 => /lib/libc.so.6 (0xdeadbeef)
        ld-linux.so.3 => /lib/ld-linux.so.3 (0xdeadbeef)
        libpthread.so.0 => /lib/libpthread.so.0 (0xdeadbeef)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xdeadbeef)

which are all in the x-tools sysroot.

Supposing, I wanted to do away with the bindmount of /lib, I'd like to
place all these libraries to some /alternate/location

How/where do I setup ct-ng to build the toolchain with the sysroot
libs in ~/x-tools/.../.../alternate/location, so these are then linked
against?
-- 
白い熊

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: glibc 2.16.0

[白い熊]

On Tue, Dec 18, 2012 at 12:10 AM, Bernhard Walle <bernhard@bwalle.de> wrote:
> You can change the interpreter when compiling with
>
>     gcc ... -Wl,-dynamic-linker,/my/lib/ld-linux.so.2 ...

More systematically, should I set the '-Wl...' in CFLAGS or LDFLAGS?
-- 
白い熊

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: glibc 2.16.0

[Bernhard Walle]

Hi,

* 白い熊 <ShiroiKuma@ShiroiKuma.org> [2012-12-18 10:13]:
> On Tue, Dec 18, 2012 at 12:10 AM, Bernhard Walle <bernhard@bwalle.de> wrote:
> > You can change the interpreter when compiling with
> >
> >     gcc ... -Wl,-dynamic-linker,/my/lib/ld-linux.so.2 ...
> 
> More systematically, should I set the '-Wl...' in CFLAGS or LDFLAGS?

LDFLAGS because it's a linker flag. The -Wl means that this option is
passed to the linker, i.e. ld is called as as

    ld ... -dynamic-linker /my/lib/ld-linux.so.2 ...


Regards,
Bernhard

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: glibc 2.16.0

[白い熊]

On Tue, Dec 18, 2012 at 12:52 AM, 白い熊 <ShiroiKuma@shiroikuma.org> wrote:
> And a followup question to this:
>
> Looking for instance at ldd of the tar binary, it links to:
>         librt.so.1 => /lib/librt.so.1 (0xdeadbeef)
>         libc.so.6 => /lib/libc.so.6 (0xdeadbeef)
>         ld-linux.so.3 => /lib/ld-linux.so.3 (0xdeadbeef)
>         libpthread.so.0 => /lib/libpthread.so.0 (0xdeadbeef)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xdeadbeef)
>
> which are all in the x-tools sysroot.
>
> Supposing, I wanted to do away with the bindmount of /lib, I'd like to
> place all these libraries to some /alternate/location
>
> How/where do I setup ct-ng to build the toolchain with the sysroot
> libs in ~/x-tools/.../.../alternate/location, so these are then linked
> against?

So, I've been inspecting the different options available from 'ct-ng
menuconfig'.

It seems to me the way to achieve this is via some extra config lines
somewhere, but where and what exactly. Some prefix syntax? Any
pointers?
-- 
白い熊

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: glibc 2.16.0

[Anthony Foiani]

Greetings --

On Tue, Dec 18, 2012 at 2:48 AM, 白い熊 <ShiroiKuma@shiroikuma.org> wrote:
> So, I've been inspecting the different options available from 'ct-ng
> menuconfig'.
>
> It seems to me the way to achieve this is via some extra config lines
> somewhere, but where and what exactly. Some prefix syntax? Any
> pointers?

You can press the "/" key to do a string (maybe regex, never checked)
search across all config symbols.

Searching for LDFLAGS, I find:

  │ Symbol: TARGET_LDFLAGS [=]
  │ Type  : string
  │ Prompt: Target LDFLAGS
  │   Defined at config/target.in:337
  │   Location:
  │     -> Target options

See if that does what you need?

Good luck!

Best regards,
Anthony Foiani

--
For unsubscribe information see http://sourceware.org/lists.html#faq