32-bit versus 64-bit android toolchain?

32-bit versus 64-bit android toolchain?

[Robert P. J. Day]

  before i make a fool of myself on the beagleboard mailing list, i'll
ask the toolchain experts here.  there's a downloadable toolchain for
android, with utilities with names of the form
arm-none-linux-gnueabi-gcc.

  however, an attempt to compile a simple "hi, world" with that
toolchain produces:

-bash:
/home/rpjday/beagle/android/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-gcc:
/lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

  that's not surprising since there is no such linker on this system.
this is a 64-bit install of fedora 11, so what we have here is:

$ ls /lib64/ld*
/lib64/ld-2.10.1.so          /lib64/ld-lsb-x86-64.so
/lib64/ld-linux-x86-64.so.2  /lib64/ld-lsb-x86-64.so.3
$

  so what's the workaround (if any)?  my first guess is that i simply
can't use this toolchain on this system.  thoughts?

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

        Linux Consulting, Training and Annoying Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Linked In:                             http://www.linkedin.com/in/rpjday
Twitter:                                       http://twitter.com/rpjday
========================================================================

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

Re: 32-bit versus 64-bit android toolchain?

[Yann E. MORIN]

Robert,
All,

On Wednesday 20 May 2009 18:36:37 Robert P. J. Day wrote:
> before i make a fool of myself on the beagleboard mailing list, i'll
> ask the toolchain experts here.  there's a downloadable toolchain for
> android,

Unless you really want to run Android on the BeagleBoard, there's no
connection between those two. IIRC, BB uses OpenEmbedded as their
"distribution", so you don't need the "Android" toolchain: OE will
build its own toolchain, or you have the option to build your own (say,
with crosstool-NG!) and feed that to OE.

> /home/rpjday/beagle/android/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-gcc:
> /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

Installing the 32-bit compatibility libraries would be my first suggestion.
On debian, it's called 'ia32-libs'. Not sure how it's called on Fedora.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'


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

Re: 32-bit versus 64-bit android toolchain?

[Robert P. J. Day]

On Wed, 20 May 2009, Yann E. MORIN wrote:

> Robert,
> All,
>
> On Wednesday 20 May 2009 18:36:37 Robert P. J. Day wrote:

> > before i make a fool of myself on the beagleboard mailing list,
> > i'll ask the toolchain experts here.  there's a downloadable
> > toolchain for android,
>
> Unless you really want to run Android on the BeagleBoard, there's no
> connection between those two. IIRC, BB uses OpenEmbedded as their
> "distribution", so you don't need the "Android" toolchain: OE will
> build its own toolchain, or you have the option to build your own
> (say, with crosstool-NG!) and feed that to OE.
>
> > /home/rpjday/beagle/android/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-gcc:
> > /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
>
> Installing the 32-bit compatibility libraries would be my first
> suggestion. On debian, it's called 'ia32-libs'. Not sure how it's
> called on Fedora.

  a short followup on this post -- the ARM toolchain i'm talking about
is downloadable from here:

  http://www.embinux.com/download_toolchain.php

but to get it to work on my x86_64 installation of fedora 11, there
were two issues i had to resolve.

1) simple compile went looking for /lib/ld-linux.so.2, so i had to
install the "glibc.i686" 32-bit compatibility package.  no big deal.

2) i had to install the toolchain under /opt since installing it under
my personal home directory (which i like to do to avoid needing root
access) generated:

/home/rpjday/beagle/android/arm-none-linux-gnueabi/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.3/../../../../arm-none-linux-gnueabi/bin/ld:
cannot find /opt/arm-none-linux-gnueabi/lib/libc.so.6 collect2: ld
returned 1 exit status

which tells me that the toolchain is not relocatable.  which is kind
of annoying.  surely it's not hard to create relocatable toolchains
these days, is it?  in any event, once i moved it to /opt, i got a
successful compile of "hi, world".

  has anyone gone to the trouble of creating an equivalent toolchain
using crosstool-ng?  if i get the time, i'll try it but i was
wondering if anyone else has been there already?  thanks.

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

        Linux Consulting, Training and Annoying Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Linked In:                             http://www.linkedin.com/in/rpjday
Twitter:                                       http://twitter.com/rpjday
========================================================================

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

Re: 32-bit versus 64-bit android toolchain?

[Yann E. MORIN]

[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

Robert,
All,

On Thursday 21 May 2009 13:07:37 Robert P. J. Day wrote:
>   a short followup on this post -- the ARM toolchain i'm talking about
> is downloadable from here:
>   http://www.embinux.com/download_toolchain.php
[--SNIP--]
>   has anyone gone to the trouble of creating an equivalent toolchain
> using crosstool-ng?  if i get the time, i'll try it but i was
> wondering if anyone else has been there already?

It's absolutely feasible, of course! I'm using a BeagleBoard too, and I
managed to build a functional toolchain targeting Cortex-A8 (not sure about
NEON, though). I don't have the .config at hand, but the attached one is
a good start.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'

[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 8777 bytes --]

#
# Automatically generated make config: don't edit
# crosstool-NG version: svn_trunk@1547M
# Thu May 21 14:26:15 2009
#

#
# Paths and misc options
#

#
# crosstool-NG behavior
#
# CT_OBSOLETE is not set
# CT_EXPERIMENTAL is not set
# CT_DEBUG_CT is not set

#
# Paths
#
CT_LOCAL_TARBALLS_DIR="${HOME}/src"
CT_SAVE_TARBALLS=y
CT_WORK_DIR="${CT_TOP_DIR}/targets"
CT_PREFIX_DIR="${HOME}/x-tools/${CT_TARGET}"
CT_INSTALL_DIR="${CT_PREFIX_DIR}"
# CT_CUSTOM_PATCH is not set
# CT_REMOVE_DOCS is not set
CT_INSTALL_DIR_RO=y

#
# Downloading
#
# CT_FORBID_DOWNLOAD is not set
# CT_FORCE_DOWNLOAD is not set
CT_USE_MIRROR=y
# CT_PREFER_MIRROR is not set
CT_MIRROR_BASE_URL="http://ymorin.is-a-geek.org/mirrors/"
CT_CONNECT_TIMEOUT=10
# CT_ONLY_DOWNLOAD is not set

#
# Extracting
#
# CT_FORCE_EXTRACT is not set
CT_OVERIDE_CONFIG_GUESS_SUB=y
# CT_ONLY_EXTRACT is not set

#
# Build behavior
#
CT_PARALLEL_JOBS=1
CT_LOAD=0
CT_NICE=0
CT_USE_PIPES=y
# CT_CONFIG_SHELL_ASH is not set

#
# Logging
#
# CT_LOG_ERROR is not set
# CT_LOG_WARN is not set
# CT_LOG_INFO is not set
CT_LOG_EXTRA=y
# CT_LOG_DEBUG is not set
# CT_LOG_ALL is not set
CT_LOG_LEVEL_MAX="EXTRA"
# CT_LOG_SEE_TOOLS_WARN is not set
CT_LOG_PROGRESS_BAR=y
CT_LOG_TO_FILE=y
CT_LOG_FILE_COMPRESS=y

#
# Target options
#
CT_ARCH="arm"
# CT_ARCH_64 is not set
# CT_ARCH_SUPPORTS_BOTH_MMU is not set
CT_ARCH_SUPPORTS_BOTH_ENDIAN=y
CT_ARCH_SUPPORT_ARCH=y
# CT_ARCH_SUPPORT_ABI is not set
CT_ARCH_SUPPORT_CPU=y
CT_ARCH_SUPPORT_TUNE=y
CT_ARCH_SUPPORT_FPU=y
# CT_ARCH_DEFAULT_HAS_MMU is not set
# CT_ARCH_DEFAULT_BE is not set
CT_ARCH_DEFAULT_LE=y
CT_ARCH_ARCH=""
CT_ARCH_CPU="cortex-a8"
CT_ARCH_TUNE="cortex-a8"
CT_ARCH_FPU=""
# CT_ARCH_BE is not set
CT_ARCH_LE=y
# CT_ARCH_FLOAT_HW is not set
CT_ARCH_FLOAT_SW=y
CT_TARGET_CFLAGS=""
CT_TARGET_LDFLAGS=""

#
# General target options
#
# CT_ARCH_alpha is not set
CT_ARCH_arm=y
# CT_ARCH_ia64 is not set
# CT_ARCH_mips is not set
# CT_ARCH_powerpc is not set
# CT_ARCH_powerpc64 is not set
# CT_ARCH_sh is not set
# CT_ARCH_x86 is not set
# CT_ARCH_x86_64 is not set
CT_ARCH_ARM_EABI=y
CT_ARCH_USE_MMU=y

#
# Target optimisations
#

#
# Toolchain options
#

#
# General toolchain options
#
CT_USE_SYSROOT=y
CT_SYSROOT_DIR_PREFIX=""
CT_SHARED_LIBS=y

#
# Tuple completion and aliasing
#
CT_TARGET_VENDOR="none"
CT_TARGET_ALIAS_SED_EXPR=""
CT_TARGET_ALIAS=""

#
# Toolchain type
#
# CT_NATIVE is not set
CT_CROSS=y
# CT_CROSS_NATIVE is not set
# CT_CANADIAN is not set
CT_TOOLCHAIN_TYPE="cross"

#
# Build system
#
CT_BUILD=""
CT_BUILD_PREFIX=""
CT_BUILD_SUFFIX=""

#
# Operating System
#
# CT_BARE_METAL is not set
CT_KERNEL="linux"
CT_KERNEL_VERSION="2.6.29.2"
# CT_KERNEL_bare_metal is not set
CT_KERNEL_linux=y
CT_KERNEL_LINUX_INSTALL=y
CT_KERNEL_LINUX_INSTALL_CHECK=y
# CT_KERNEL_V_2_6_18_8 is not set
# CT_KERNEL_V_2_6_19_7 is not set
# CT_KERNEL_V_2_6_20_21 is not set
# CT_KERNEL_V_2_6_21_7 is not set
# CT_KERNEL_V_2_6_22_19 is not set
# CT_KERNEL_V_2_6_23_17 is not set
# CT_KERNEL_V_2_6_24_7 is not set
# CT_KERNEL_V_2_6_25_20 is not set
# CT_KERNEL_V_2_6_26_8 is not set
# CT_KERNEL_V_2_6_27_22 is not set
# CT_KERNEL_V_2_6_28 is not set
# CT_KERNEL_V_2_6_28_1 is not set
# CT_KERNEL_V_2_6_28_2 is not set
# CT_KERNEL_V_2_6_28_3 is not set
# CT_KERNEL_V_2_6_28_4 is not set
# CT_KERNEL_V_2_6_28_5 is not set
# CT_KERNEL_V_2_6_28_6 is not set
# CT_KERNEL_V_2_6_28_7 is not set
# CT_KERNEL_V_2_6_28_8 is not set
# CT_KERNEL_V_2_6_28_9 is not set
# CT_KERNEL_V_2_6_28_10 is not set
# CT_KERNEL_V_2_6_29 is not set
# CT_KERNEL_V_2_6_29_1 is not set
CT_KERNEL_V_2_6_29_2=y
# CT_KERNEL_V_select is not set
CT_KERNEL_LINUX_VERBOSITY_0=y
# CT_KERNEL_LINUX_VERBOSITY_1 is not set
# CT_KERNEL_LINUX_VERBOSITY_2 is not set
CT_KERNEL_LINUX_VERBOSE_LEVEL=0
# CT_KERNEL_LINUX_USE_CUSTOM_HEADERS is not set

#
# Companion libraries
#
CT_GMP_MPFR=y
CT_GMP_MPFR_TARGET=y
# CT_GMP_V_4_2_2 is not set
CT_GMP_V_4_2_4=y
CT_GMP_VERSION="4.2.4"
# CT_GMP_CHECK is not set
# CT_MPFR_V_2_3_1 is not set
# CT_MPFR_V_2_3_2 is not set
# CT_MPFR_V_2_4_0 is not set
CT_MPFR_V_2_4_1=y
CT_MPFR_VERSION="2.4.1"
# CT_MPFR_CHECK is not set
# CT_PPL_CLOOG is not set

#
# Binary utilities
#
CT_ARCH_BINFMT_ELF=y
# CT_ARCH_BINFMT_FLAT is not set

#
# GNU binutils
#
CT_BINUTILS_VERSION="2.19.1"
# CT_BINUTILS_V_2_14 is not set
# CT_BINUTILS_V_2_15 is not set
# CT_BINUTILS_V_2_16_1 is not set
# CT_BINUTILS_V_2_17 is not set
# CT_BINUTILS_V_2_18 is not set
# CT_BINUTILS_V_2_18_50_0_4 is not set
# CT_BINUTILS_V_2_18_50_0_6 is not set
# CT_BINUTILS_V_2_18_50_0_7 is not set
# CT_BINUTILS_V_2_18_50_0_8 is not set
# CT_BINUTILS_V_2_18_50_0_9 is not set
# CT_BINUTILS_V_2_18_90 is not set
# CT_BINUTILS_V_2_18_91 is not set
# CT_BINUTILS_V_2_18_92 is not set
# CT_BINUTILS_V_2_18_93 is not set
# CT_BINUTILS_V_2_19 is not set
CT_BINUTILS_V_2_19_1=y
# CT_BINUTILS_V_2_19_50_0_1 is not set
# CT_BINUTILS_V_2_19_51_0_1 is not set
# CT_BINUTILS_V_2_19_51_0_2 is not set
CT_BINUTILS_EXTRA_CONFIG=""
CT_BINUTILS_FOR_TARGET=y
CT_BINUTILS_FOR_TARGET_IBERTY=y
CT_BINUTILS_FOR_TARGET_BFD=y

#
# C compiler
#
CT_CC="gcc"
CT_CC_VERSION="4.3.3"
CT_CC_gcc=y
# CT_CC_V_3_2_3 is not set
# CT_CC_V_3_3_6 is not set
# CT_CC_V_3_4_6 is not set
# CT_CC_V_4_0_0 is not set
# CT_CC_V_4_0_1 is not set
# CT_CC_V_4_0_2 is not set
# CT_CC_V_4_0_3 is not set
# CT_CC_V_4_0_4 is not set
# CT_CC_V_4_1_0 is not set
# CT_CC_V_4_1_1 is not set
# CT_CC_V_4_1_2 is not set
# CT_CC_V_4_2_0 is not set
# CT_CC_V_4_2_1 is not set
# CT_CC_V_4_2_2 is not set
# CT_CC_V_4_2_3 is not set
# CT_CC_V_4_2_4 is not set
# CT_CC_V_4_3_0 is not set
# CT_CC_V_4_3_1 is not set
# CT_CC_V_4_3_2 is not set
CT_CC_V_4_3_3=y
# CT_CC_V_4_4_0 is not set
CT_CC_GCC_4_3_or_later=y
# CT_CC_GCC_4_4_or_later is not set
CT_CC_CXA_ATEXIT=y
# CT_CC_SJLJ_EXCEPTIONS_CONFIGURE is not set
# CT_CC_SJLJ_EXCEPTIONS_USE is not set
CT_CC_SJLJ_EXCEPTIONS_DONT_USE=y
CT_CC_CORE_EXTRA_CONFIG=""
CT_CC_EXTRA_CONFIG=""
CT_CC_PKGVERSION="crosstool-NG-${CT_VERSION}"
CT_CC_BUGURL=""
CT_CC_SUPPORT_CXX=y
CT_CC_SUPPORT_FORTRAN=y
CT_CC_SUPPORT_JAVA=y
CT_CC_SUPPORT_ADA=y
CT_CC_SUPPORT_OBJC=y
CT_CC_SUPPORT_OBJCXX=y

#
# Additional supported languages:
#
CT_CC_LANG_CXX=y
# CT_CC_LANG_FORTRAN is not set
# CT_CC_LANG_JAVA is not set
CT_LIBC="glibc"

#
# C-library
#
CT_LIBC_VERSION="2.9"
# CT_LIBC_eglibc is not set
CT_LIBC_glibc=y
# CT_LIBC_uClibc is not set
# CT_LIBC_V_2_3_6 is not set
# CT_LIBC_V_2_5 is not set
# CT_LIBC_V_2_5_1 is not set
# CT_LIBC_V_2_6 is not set
# CT_LIBC_V_2_6_1 is not set
# CT_LIBC_V_2_7 is not set
# CT_LIBC_V_2_8 is not set
CT_LIBC_V_2_9=y
# CT_LIBC_V_LATEST is not set
# CT_LIBC_V_date is not set
CT_LIBC_GLIBC_2_8_or_later=y
# CT_LIBC_GLIBC_TARBALL is not set
CT_LIBC_GLIBC_CVS=y
CT_LIBC_GLIBC_CVS_date="2009-03-29"

#
# glibc/eglibc common options
#
CT_LIBC_GLIBC_EXTRA_CONFIG=""
CT_LIBC_GLIBC_CONFIGPARMS=""
CT_LIBC_GLIBC_EXTRA_CFLAGS=""
CT_LIBC_EXTRA_CC_ARGS=""
CT_LIBC_GLIBC_USE_PORTS=y
CT_LIBC_ADDONS_LIST=""

#
# WARNING!!!
#

#
# For glibc >= 2.8, addons are only available via a CVS checkout.
#

#
# Be sure to review the associated options, above.
#
# CT_LIBC_GLIBC_KERNEL_VERSION_NONE is not set
CT_LIBC_GLIBC_KERNEL_VERSION_AS_HEADERS=y
# CT_LIBC_GLIBC_KERNEL_VERSION_CHOSEN is not set
CT_LIBC_GLIBC_MIN_KERNEL="2.6.29.2"

#
# Common C library options
#
CT_LIBC_SUPPORT_NPTL=y
CT_LIBC_SUPPORT_LINUXTHREADS=y
CT_THREADS="nptl"
CT_THREADS_NPTL=y
# CT_THREADS_LINUXTHREADS is not set
# CT_THREADS_NONE is not set

#
# Tools facilities
#
CT_TOOL_libelf=y
CT_LIBELF_V_0_8_10=y
CT_LIBELF_VERSION="0.8.10"
CT_TOOL_sstrip=y
CT_SSTRIP_BUILDROOT=y
# CT_SSTRIP_ELFKICKERS is not set
CT_SSTRIP_FROM="buildroot"

#
# Debug facilities
#
CT_DEBUG_dmalloc=y
# CT_DMALLOC_V_5_4_3 is not set
CT_DMALLOC_V_5_5_2=y
CT_DMALLOC_VERSION="5.5.2"
CT_DEBUG_duma=y
CT_DUMA_A=y
CT_DUMA_SO=y
# CT_DUMA_V_2_5_1 is not set
# CT_DUMA_V_2_5_8 is not set
# CT_DUMA_V_2_5_12 is not set
CT_DUMA_V_2_5_14=y
CT_DUMA_VERSION="2_5_14"
CT_DEBUG_gdb=y
CT_GDB_CROSS=y
# CT_GDB_CROSS_STATIC is not set
CT_GDB_NATIVE=y
# CT_GDB_NATIVE_STATIC is not set
CT_GDB_NATIVE_USE_GMP_MPFR=y
CT_GDB_GDBSERVER=y
CT_GDB_GDBSERVER_STATIC=y
# CT_GDB_V_6_4 is not set
# CT_GDB_V_6_5 is not set
# CT_GDB_V_6_6 is not set
# CT_GDB_V_6_7 is not set
# CT_GDB_V_6_7_1 is not set
CT_GDB_V_6_8=y
# CT_GDB_V_snapshot is not set
CT_GDB_VERSION="6.8"

#
# Native gdb needs a native ncurses library
#
# CT_NCURSES_V_5_6 is not set
CT_NCURSES_V_5_7=y
CT_NCURSES_VERSION="5.7"
CT_DEBUG_ltrace=y
# CT_LTRACE_V_0_4 is not set
CT_LTRACE_V_0_5=y
# CT_LTRACE_V_0_5_1 is not set
CT_LTRACE_VERSION="0.5"
CT_DEBUG_strace=y
# CT_STRACE_V_4_5 is not set
# CT_STRACE_V_4_5_14 is not set
# CT_STRACE_V_4_5_15 is not set
# CT_STRACE_V_4_5_16 is not set
CT_STRACE_V_4_5_17=y
# CT_STRACE_V_4_5_18 is not set
CT_STRACE_VERSION="4.5.17"


[-- Attachment #3: Type: text/plain, Size: 71 bytes --]

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

Re: 32-bit versus 64-bit android toolchain?

[Robert P. J. Day]

On Wed, 20 May 2009, Yann E. MORIN wrote:

> Robert,
> All,
>
> On Wednesday 20 May 2009 18:36:37 Robert P. J. Day wrote:
> > before i make a fool of myself on the beagleboard mailing list,
> > i'll ask the toolchain experts here.  there's a downloadable
> > toolchain for android,
>
> Unless you really want to run Android on the BeagleBoard, there's no
> connection between those two. IIRC, BB uses OpenEmbedded as their
> "distribution", so you don't need the "Android" toolchain: OE will
> build its own toolchain, or you have the option to build your own
> (say, with crosstool-NG!) and feed that to OE.
>
> > /home/rpjday/beagle/android/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-gcc:
> > /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
>
> Installing the 32-bit compatibility libraries would be my first
> suggestion. On debian, it's called 'ia32-libs'. Not sure how it's
> called on Fedora.

  for the record, on fedora 11, it's the "glibc.i686" package.  duh.

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

        Linux Consulting, Training and Annoying Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Linked In:                             http://www.linkedin.com/in/rpjday
Twitter:                                       http://twitter.com/rpjday
========================================================================

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

Re: 32-bit versus 64-bit android toolchain?

[Robert P. J. Day]

On Thu, 21 May 2009, Yann E. MORIN wrote:

> Robert,
> All,
>
> On Thursday 21 May 2009 13:07:37 Robert P. J. Day wrote:
> >   a short followup on this post -- the ARM toolchain i'm talking about
> > is downloadable from here:
> >   http://www.embinux.com/download_toolchain.php
> [--SNIP--]
> >   has anyone gone to the trouble of creating an equivalent toolchain
> > using crosstool-ng?  if i get the time, i'll try it but i was
> > wondering if anyone else has been there already?
>
> It's absolutely feasible, of course! I'm using a BeagleBoard too, and I
> managed to build a functional toolchain targeting Cortex-A8 (not sure about
> NEON, though). I don't have the .config at hand, but the attached one is
> a good start.

  thanks.  can you keep me up-to-date on any improvements to the
toolchain build for the beagle?  i'm documenting my adventures on the
beagle here:

http://www.crashcourse.ca/wiki/index.php/BeagleBoard

in case anyone's interested.  what i found is that there's *lots* of
BB info out there, but it's annoyingly scattered, so i figured i'd
start putting it in one place for beginners.  right now, i'm trying to
document the various toolchains available.

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

        Linux Consulting, Training and Annoying Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Linked In:                             http://www.linkedin.com/in/rpjday
Twitter:                                       http://twitter.com/rpjday
========================================================================

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

Re: 32-bit versus 64-bit android toolchain?

[Thomas Petazzoni]

Le Thu, 21 May 2009 07:07:37 -0400 (EDT),
"Robert P. J. Day" <rpjday@crashcourse.ca> a écrit :

> which tells me that the toolchain is not relocatable.  which is kind
> of annoying.  surely it's not hard to create relocatable toolchains
> these days, is it?  in any event, once i moved it to /opt, i got a
> successful compile of "hi, world".

Starting with gcc 4.x, toolchains can support the "sysroot"
functionnality (this is optional). It allows to change the installation
location of the toolchain, but if you do change this installation
location, then you must pass a --sysroot option pointing to the
directory where the toolchain is installed. So toolchains based on gcc
4.x compiled with sysroot support are relocatable, but it requires some
explicit flag passed by the user.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

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

Re: 32-bit versus 64-bit android toolchain?

[Yann E. MORIN]

Thomas,
All,

On Friday 22 May 2009 19:27:53 Thomas Petazzoni wrote:
> Starting with gcc 4.x, toolchains can support the "sysroot"
> functionnality (this is optional). It allows to change the installation
> location of the toolchain, but if you do change this installation
> location, then you must pass a --sysroot option pointing to the
> directory where the toolchain is installed. So toolchains based on gcc
> 4.x compiled with sysroot support are relocatable, but it requires some
> explicit flag passed by the user.

Passing --sysroot at runtime should not be needed. From the gcc installation
instructions:

-----8<-----
  --with-sysroot=dir
    [...] If the specified directory is a subdirectory of ${exec_prefix},
    then it will be found relative to the GCC binaries if the installation
    tree is moved.
-----8<-----

And from my experiments, it works as advertised, for once! :-]

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'


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

linking correct libc

[ng]

Yann E. MORIN wrote:
> Thomas,
> All,
> 
> On Friday 22 May 2009 19:27:53 Thomas Petazzoni wrote:
>> Starting with gcc 4.x, toolchains can support the "sysroot"
>> functionnality (this is optional). It allows to change the installation
>> location of the toolchain, but if you do change this installation
>> location, then you must pass a --sysroot option pointing to the
>> directory where the toolchain is installed. So toolchains based on gcc
>> 4.x compiled with sysroot support are relocatable, but it requires some
>> explicit flag passed by the user.
> 
> Passing --sysroot at runtime should not be needed. From the gcc installation
> instructions:
> 
> -----8<-----
>   --with-sysroot=dir
>     [...] If the specified directory is a subdirectory of ${exec_prefix},
>     then it will be found relative to the GCC binaries if the installation
>     tree is moved.
> -----8<-----
> 
> And from my experiments, it works as advertised, for once! :-]
> 
> Regards,
> Yann E. MORIN.
> 

Hi ,

this question of --sysroot is giving me problems

   CFLAGS="-march=armv4t" 
CPPFLAGS="--sysroot=/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/ 
-I/back/ts/root2/usr/include"  LDFLAGS="-L/back/ts/root2/usr/lib/" make
arm-unknown-linux-gnueabi-gcc -L/back/ts/root2/usr/lib/ -pie  portmap.o 
pmap_check.o from_local.o  -lwrap -o portmap
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
cannot find /lib/libc.so.6
collect2: ld returned 1 exit status
make: *** [portmap] Error 1


the -I and -L options enable it to find the headers tcpd.h and to link 
-lwrap , however it seems to hit the HOST libc instead of the eabi 
build. I'm not even sure why the cross-compiled ld is looking /lib

Is this just me misusing the tools or is something incorrectly configured.

I have a working kernel and  busybox (ie it boots), and untested be 
clean installations of tcp-wrappers, sysvinit, gzip zlib and dropbear 
but I've spend several days now banging my head on this libc problem.

Thanks for any help in getting this moving forwards.


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

Re: linking correct libc

[ng]

Hi,

trying --sysroot was one of my desperate attempts to get some sense out 
of this toolchain. I have now dumped the idea.


  CFLAGS="-march=armv4t" CPPFLAGS="-I/back/ts/root2/usr/include" 
LDFLAGS="-L/back/ts/root2/usr/lib/ 
-L/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib" 
make


...
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
cannot find /lib/libc.so.6
collect2: ld returned 1 exit status
make: *** [pmap_dump] Error 1
pr


adding -nostdlib stops it finding the host libc but stops it finding any 
libc:


  CFLAGS="-march=armv4t" CPPFLAGS="-I/back/ts/root2/usr/include" 
LDFLAGS="-L/back/ts/root2/usr/lib/ 
-L/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib 
-nostdlib" make

...

/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
warning: cannot find entry symbol _start; defaulting to 000080b4
pmap_dump.o: In function `main':
pmap_dump.c:(.text+0x28): undefined reference to `memset'
pmap_dump.c:(.text+0x3c): undefined reference to `htonl'
pmap_dump.c:(.text+0x4c): undefined reference to `htons'
pmap_dump.c:(.text+0x60): undefined reference to `pmap_getmaps'
pmap_dump.c:(.text+0x7c): undefined reference to `getrpcbynumber'
pmap_dump.c:(.text+0x104): undefined reference to `printf'
pmap_dump.c:(.text+0x12c): undefined reference to `fclose'
pmap_dump.c:(.text+0x148): undefined reference to `perror'
pmap_dump.c:(.text+0x17c): undefined reference to `stdout'
pmap_dump.o: In function `protoname':
pmap_dump.c:(.text+0x1d8): undefined reference to `sprintf'
collect2: ld returned 1 exit status
make: *** [pmap_dump] Error 1


  file pmap_dump.o
pmap_dump.o: ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), not stripped


  file 
/back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib/libc.so.6 

/back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib/libc.so.6: 
symbolic link to `libc-2.9.so'

file 
/back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib/libc-2.9.so
/back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib/libc-2.9.so: 
ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked 
(uses shared libs), for GNU/Linux 2.6.29, not stripped


So the two basic issues remain: why does it find /lib/libc.so.6 at all 
and why can't it find (or use) the library that exists in the libdir 
explicitly included with -L ??


This one issue has consumed a lot of time , any help would be appreciated.

regards, Peter.

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

Re: linking correct libc

[Yann E. MORIN]

On Saturday 23 May 2009 17:40:41 ng@piments.com wrote:
> trying --sysroot was one of my desperate attempts to get some sense out 
> of this toolchain. I have now dumped the idea.

It is *not* needed to pass --sysroot to the compielrs build with
crosstool-NG.

> adding -nostdlib stops it finding the host libc but stops it finding any 
> libc:

That's exactly the purpose of -nostdlib: to not use standard libraries.

> So the two basic issues remain: why does it find /lib/libc.so.6 at all 
> and why can't it find (or use) the library that exists in the libdir 
> explicitly included with -L ??

What does the follwing command says:
/back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc \

And what does that one says:
/back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc \
-print-file-name=libc.so

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'


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

Re: linking correct libc

[ng]

Yann E. MORIN wrote:
> On Saturday 23 May 2009 17:40:41 ng@piments.com wrote:
>> trying --sysroot was one of my desperate attempts to get some sense out 
>> of this toolchain. I have now dumped the idea.
> 
> It is *not* needed to pass --sysroot to the compielrs build with
> crosstool-NG.

thanks, I realised that , it was an attempt to verofu what was happening 
by explicitly specifying everything. When it made no difference I 
concluded the built-in sysroot was correctly interpreted and the problem 
lay elsewhere.

> 
>> adding -nostdlib stops it finding the host libc but stops it finding any 
>> libc:
> 
> That's exactly the purpose of -nostdlib: to not use standard libraries.


> 
>> So the two basic issues remain: why does it find /lib/libc.so.6 at all 
>> and why can't it find (or use) the library that exists in the libdir 
>> explicitly included with -L ??
> 
> What does the follwing command says:
> /back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc \
> 
was something missed off after the \   :?

/back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc 

arm-unknown-linux-gnueabi-gcc: no input files


> And what does that one says:
> /back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc \
> -print-file-name=libc.so
> 
 
/back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc 
\ -print-file-name=libc.so
/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/usr/lib/libc.so

cat 
/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/usr/lib/libc.so
/* GNU ld script
    Use the shared library, but some functions are only in
    the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-littlearm)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( 
/lib/ld-linux.so.3 ) )



OK , so that explains the reference to /lib/libc.so.6 , is that what you 
would expect to see here?

Thanks for your help,
Peter.

> Regards,
> Yann E. MORIN.
> 


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

Re: linking correct libc

[Yann E. MORIN]

"ng",
All,

On Sunday 24 May 2009 22:09:27 ng@piments.com wrote:
> Yann E. MORIN wrote:
> > It is *not* needed to pass --sysroot to the compielrs build with
> > crosstool-NG.
> thanks, I realised that , it was an attempt to verofu what was happening 
> by explicitly specifying everything. When it made no difference I 
> concluded the built-in sysroot was correctly interpreted and the problem 
> lay elsewhere.

So, your toolchain is working, and you are trying to reproduce gcc's internal
logic by passing args on the command line, right?

> > What does the follwing command says:
> > /back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc \
> was something missed off after the \   :?

Yes, sorry:
bla-bla-gcc -print-search-dirs

> /back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc 
> \ -print-file-name=libc.so
> /back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/usr/lib/libc.so

OK.

> cat 
> /back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/usr/lib/libc.so
> /* GNU ld script
>     Use the shared library, but some functions are only in
>     the static library, so try that secondarily.  */
> OUTPUT_FORMAT(elf32-littlearm)
> GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( 
> /lib/ld-linux.so.3 ) )
> OK , so that explains the reference to /lib/libc.so.6 , is that what you 
> would expect to see here?

Yes, correct. Those are paths relative to the sysroot, so gcc will hapilly
find them.
BTW, notice: ld-linux.so.3 -> EABI-era dynamic linker, good.

To conclude this thread: does your toolchain correctly works by default?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'


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

Re: linking correct libc

[ng]

Yann E. MORIN wrote:
> "ng",
> All,
> 
> On Sunday 24 May 2009 22:09:27 ng@piments.com wrote:
>> Yann E. MORIN wrote:
>>> It is *not* needed to pass --sysroot to the compielrs build with
>>> crosstool-NG.
>> thanks, I realised that , it was an attempt to verofu what was happening 
>> by explicitly specifying everything. When it made no difference I 
>> concluded the built-in sysroot was correctly interpreted and the problem 
>> lay elsewhere.
> 
> So, your toolchain is working, and you are trying to reproduce gcc's internal
> logic by passing args on the command line, right?
> 
>>> What does the follwing command says:
>>> /back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc \
>> was something missed off after the \   :?
> 
> Yes, sorry:
> bla-bla-gcc -print-search-dirs
voila:

/back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc 
-print-search-dirs
install: 
/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.3.2/
programs: 
=/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../libexec/gcc/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../libexec/gcc/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/
libraries: 
=/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/lib/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/lib/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/lib/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/lib/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/usr/lib/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/usr/lib/

> 
>> /back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc 
>> \ -print-file-name=libc.so
>> /back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/usr/lib/libc.so
> 
> OK.
> 
>> cat 
>> /back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/usr/lib/libc.so
>> /* GNU ld script
>>     Use the shared library, but some functions are only in
>>     the static library, so try that secondarily.  */
>> OUTPUT_FORMAT(elf32-littlearm)
>> GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( 
>> /lib/ld-linux.so.3 ) )
>> OK , so that explains the reference to /lib/libc.so.6 , is that what you 
>> would expect to see here?
> 
> Yes, correct. Those are paths relative to the sysroot, so gcc will hapilly
> find them.
> BTW, notice: ld-linux.so.3 -> EABI-era dynamic linker, good.
> 
> To conclude this thread: does your toolchain correctly works by default?
> 
Well it builds a bootable kernel and busybox but I can't get past this 
incompatible /lib/libc.so.6 error in portmap.


  CPPFLAGS="-I/back/ts/root2/usr/include" 
LDFLAGS="-L/back/ts/root2/usr/lib/" make
arm-unknown-linux-gnueabi-gcc -L/back/ts/root2/usr/lib/ -pie  portmap.o 
pmap_check.o from_local.o  -lwrap -o portmap
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
cannot find /lib/libc.so.6
collect2: ld returned 1 exit status
make: *** [portmap] Error 1


Since that /lib/libc.so.6 would appear to be the sys-root one and you 
say that file looks good, why is it crapping out and declaring this file 
"incompatible"?

Thanks again.


> Regards,
> Yann E. MORIN.
> 


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

Re: linking correct libc

[ng]

ng@piments.com wrote:
> Yann E. MORIN wrote:
>> "ng",
>> All,
>>
>> On Sunday 24 May 2009 22:09:27 ng@piments.com wrote:
>>> Yann E. MORIN wrote:
>>>> It is *not* needed to pass --sysroot to the compielrs build with
>>>> crosstool-NG.
>>> thanks, I realised that , it was an attempt to verofu what was 
>>> happening by explicitly specifying everything. When it made no 
>>> difference I concluded the built-in sysroot was correctly interpreted 
>>> and the problem lay elsewhere.
>>
>> So, your toolchain is working, and you are trying to reproduce gcc's 
>> internal
>> logic by passing args on the command line, right?
>>
>>>> What does the follwing command says:
>>>> /back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc 
>>>> \
>>> was something missed off after the \   :?
>>
>> Yes, sorry:
>> bla-bla-gcc -print-search-dirs
> voila:
> 
> /back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc 
> -print-search-dirs
> install: 
> /back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.3.2/ 
> 
> programs: 
> =/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../libexec/gcc/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../libexec/gcc/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ 
> 
> libraries: 
> =/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/lib/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/lib/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/lib/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/lib/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/usr/lib/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/usr/lib/ 
> 
> 
>>
>>> /back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc 
>>> \ -print-file-name=libc.so
>>> /back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/usr/lib/libc.so 
>>>
>>
>> OK.
>>
>>> cat 
>>> /back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/usr/lib/libc.so 
>>>
>>> /* GNU ld script
>>>     Use the shared library, but some functions are only in
>>>     the static library, so try that secondarily.  */
>>> OUTPUT_FORMAT(elf32-littlearm)
>>> GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( 
>>> /lib/ld-linux.so.3 ) )
>>> OK , so that explains the reference to /lib/libc.so.6 , is that what 
>>> you would expect to see here?
>>
>> Yes, correct. Those are paths relative to the sysroot, so gcc will 
>> hapilly
>> find them.
>> BTW, notice: ld-linux.so.3 -> EABI-era dynamic linker, good.
>>
>> To conclude this thread: does your toolchain correctly works by default?
>>
> Well it builds a bootable kernel and busybox but I can't get past this 
> incompatible /lib/libc.so.6 error in portmap.
> 
> 
>  CPPFLAGS="-I/back/ts/root2/usr/include" 
> LDFLAGS="-L/back/ts/root2/usr/lib/" make
> arm-unknown-linux-gnueabi-gcc -L/back/ts/root2/usr/lib/ -pie  portmap.o 
> pmap_check.o from_local.o  -lwrap -o portmap
> /back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
> skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
> /back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
> cannot find /lib/libc.so.6
> collect2: ld returned 1 exit status
> make: *** [portmap] Error 1
> 
> 
> Since that /lib/libc.so.6 would appear to be the sys-root one and you 
> say that file looks good, why is it crapping out and declaring this file 
> "incompatible"?
> 
> Thanks again.
> 
> 
>> Regards,
>> Yann E. MORIN.
>>
> 
> 

Hi Yann,

based on the information on this problem which seems pretty complete now 
, can you please explain why I am unable to compile this package?


 >> To conclude this thread: does your toolchain correctly works by default?

What do you mean by "by default"? This is the minimum ammount of 
variables I need to supply to get some of the files to build upto the 
point were it declares libc.so.6 "incompatible".


  echo $CC
arm-unknown-linux-gnueabi-gcc

   CFLAGS="-march=armv4t"  CPPFLAGS="-I/back/ts/root2/usr/include" 
LDFLAGS="-L/back/ts/root2/usr/lib/"  make
arm-unknown-linux-gnueabi-gcc -march=armv4t -Wall -Wstrict-prototypes 
-fpie -I/back/ts/root2/usr/include -DHOSTS_ACCESS -DCHECK_PORT 
-DIGNORE_SIGCHLD    -DFACILITY=LOG_DAEMON   -c -o portmap.o portmap.c
arm-unknown-linux-gnueabi-gcc -march=armv4t -Wall -Wstrict-prototypes 
-fpie -I/back/ts/root2/usr/include -DHOSTS_ACCESS -DCHECK_PORT 
-DIGNORE_SIGCHLD    -DFACILITY=LOG_DAEMON   -c -o pmap_check.o pmap_check.c
arm-unknown-linux-gnueabi-gcc -march=armv4t -Wall -Wstrict-prototypes 
-fpie -I/back/ts/root2/usr/include -DHOSTS_ACCESS -DCHECK_PORT 
-DIGNORE_SIGCHLD    -DFACILITY=LOG_DAEMON   -c -o from_local.o from_local.c
arm-unknown-linux-gnueabi-gcc -L/back/ts/root2/usr/lib/ -pie  portmap.o 
pmap_check.o from_local.o  -lwrap -o portmap
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
cannot find /lib/libc.so.6
collect2: ld returned 1 exit status
make: *** [portmap] Error 1


So I would say : no, the toolchain is not working correctly in this case.



So I see a limited number of explainations.

1/ It is really finding /lib/libc.so.6 (ie the host x86 library) as 
indicated by the output but contrary to the -print-search-dirs paths.

2/ It is looking in the right place but finding something different to 
what is expected.

3/ It is finding a good libc but erroneously calling it incompatible.

4/ It is finding another libc in the search path but there is not:
  find /back/ts/ct-wkg/x-tools -iname libc.so.6 

/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib/libc.so.6

5/ I'm making some dumb error in using the toolchain.


If it was 5/ I'm sure you would have told me by now so I'm left with the 
conclusion that there is problem with the toolchain.



thanks again, Peter.






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

Re: linking correct libc

[Yann E. MORIN]

Peter,
All,

On Tuesday 26 May 2009 07:07:28 ng@piments.com wrote:
>    CFLAGS="-march=armv4t"  CPPFLAGS="-I/back/ts/root2/usr/include" 
> LDFLAGS="-L/back/ts/root2/usr/lib/"  make
> arm-unknown-linux-gnueabi-gcc -march=armv4t -Wall -Wstrict-prototypes 
> -fpie -I/back/ts/root2/usr/include -DHOSTS_ACCESS -DCHECK_PORT 
> -DIGNORE_SIGCHLD    -DFACILITY=LOG_DAEMON   -c -o portmap.o portmap.c
> arm-unknown-linux-gnueabi-gcc -march=armv4t -Wall -Wstrict-prototypes 
> -fpie -I/back/ts/root2/usr/include -DHOSTS_ACCESS -DCHECK_PORT 
> -DIGNORE_SIGCHLD    -DFACILITY=LOG_DAEMON   -c -o pmap_check.o pmap_check.c
> arm-unknown-linux-gnueabi-gcc -march=armv4t -Wall -Wstrict-prototypes 
> -fpie -I/back/ts/root2/usr/include -DHOSTS_ACCESS -DCHECK_PORT 
> -DIGNORE_SIGCHLD    -DFACILITY=LOG_DAEMON   -c -o from_local.o from_local.c

So far, all good.

> arm-unknown-linux-gnueabi-gcc -L/back/ts/root2/usr/lib/ -pie  portmap.o 
> pmap_check.o from_local.o  -lwrap -o portmap

All input .o files should be ARM files, they got build just above. Just
check libwrap is an ARM binary too, just to be sure it got cross-compiled:
file /back/ts/root2/usr/lib/libwrap.so*

If it is really an ARM file, you can run again, but setting:
LDFLAGS="-L/back/ts/root2/usr/lib/ -v -Wl,--verbose"

The output is quite verbose, but you'll see exactly what ld is trying
to do...

> So I would say : no, the toolchain is not working correctly in this case.

Not so sure... ;-)

> 1/ It is really finding /lib/libc.so.6 (ie the host x86 library) as 
> indicated by the output but contrary to the -print-search-dirs paths.

Maybe, just check libwrap, as stated above.

> 2/ It is looking in the right place but finding something different to 
> what is expected.

EABI and endianness come to mind. The verbose ld logs, above, will
tell.

> 3/ It is finding a good libc but erroneously calling it incompatible.

Nope.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'


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

Re: linking correct libc

[ng]

Yann E. MORIN wrote:
> Peter,
> All,
> 
> On Tuesday 26 May 2009 07:07:28 ng@piments.com wrote:
>>    CFLAGS="-march=armv4t"  CPPFLAGS="-I/back/ts/root2/usr/include" 
>> LDFLAGS="-L/back/ts/root2/usr/lib/"  make
>> arm-unknown-linux-gnueabi-gcc -march=armv4t -Wall -Wstrict-prototypes 
>> -fpie -I/back/ts/root2/usr/include -DHOSTS_ACCESS -DCHECK_PORT 
>> -DIGNORE_SIGCHLD    -DFACILITY=LOG_DAEMON   -c -o portmap.o portmap.c
>> arm-unknown-linux-gnueabi-gcc -march=armv4t -Wall -Wstrict-prototypes 
>> -fpie -I/back/ts/root2/usr/include -DHOSTS_ACCESS -DCHECK_PORT 
>> -DIGNORE_SIGCHLD    -DFACILITY=LOG_DAEMON   -c -o pmap_check.o pmap_check.c
>> arm-unknown-linux-gnueabi-gcc -march=armv4t -Wall -Wstrict-prototypes 
>> -fpie -I/back/ts/root2/usr/include -DHOSTS_ACCESS -DCHECK_PORT 
>> -DIGNORE_SIGCHLD    -DFACILITY=LOG_DAEMON   -c -o from_local.o from_local.c
> 
> So far, all good.
> 
>> arm-unknown-linux-gnueabi-gcc -L/back/ts/root2/usr/lib/ -pie  portmap.o 
>> pmap_check.o from_local.o  -lwrap -o portmap
> 
> All input .o files should be ARM files, they got build just above. Just
> check libwrap is an ARM binary too, just to be sure it got cross-compiled:
> file /back/ts/root2/usr/lib/libwrap.so*

file /back/ts/root2/usr/lib/libwrap.so*
/back/ts/root2/usr/lib/libwrap.so:       symbolic link to `libwrap.so.0'
/back/ts/root2/usr/lib/libwrap.so.0:     symbolic link to `libwrap.so.0.7.6'
/back/ts/root2/usr/lib/libwrap.so.0.7.6: ELF 32-bit LSB shared object, 
ARM, version 1 (SYSV), dynamically linked, not stripped


> 
> If it is really an ARM file, you can run again, but setting:
> LDFLAGS="-L/back/ts/root2/usr/lib/ -v -Wl,--verbose"
> 
> The output is quite verbose, but you'll see exactly what ld is trying
> to do...
> 
attempt to open 
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/libgcc_s.a 
failed
attempt to open 
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/lib/libgcc_s.so 
succeeded
-lgcc_s 
(/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/lib/libgcc_s.so)
attempt to open /back/ts/root2/usr/lib//libc.so succeeded
opened script file /back/ts/root2/usr/lib//libc.so
opened script file /back/ts/root2/usr/lib//libc.so
attempt to open /lib/libc.so.6 succeeded
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
cannot find /lib/libc.so.6
collect2: ld returned 1 exit status
make: *** [portmap] Error 1


>> So I would say : no, the toolchain is not working correctly in this case.
> 
> Not so sure... ;-)
> 
>> 1/ It is really finding /lib/libc.so.6 (ie the host x86 library) as 
>> indicated by the output but contrary to the -print-search-dirs paths.
> 
> Maybe, just check libwrap, as stated above.
opened script file /back/ts/root2/usr/lib//libc.so
attempt to open /lib/libc.so.6 succeeded

Maybe I should be taking this output to be the truth, it really is 
looking in /lib?

YES!

pwd
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib
rm libc.so.6

attempt to open /back/ts/root2/usr/lib//libc.so succeeded
opened script file /back/ts/root2/usr/lib//libc.so
opened script file /back/ts/root2/usr/lib//libc.so
attempt to open /lib/libc.so.6 succeeded
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
cannot find /lib/libc.so.6
collect2: ld returned 1 exit status
make: *** [portmap] Error 1


Right, finally something concrete. So now the question is why.

:?

regards.


> 
>> 2/ It is looking in the right place but finding something different to 
>> what is expected.
> 
> EABI and endianness come to mind. The verbose ld logs, above, will
> tell.
> 
>> 3/ It is finding a good libc but erroneously calling it incompatible.
> 
> Nope.
> 
> Regards,
> Yann E. MORIN.
> 


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

Re: linking correct libc

[ng]

ng@piments.com wrote:
> Hi,
> 
> trying --sysroot was one of my desperate attempts to get some sense out 
> of this toolchain. I have now dumped the idea.
> 
> 
>  CFLAGS="-march=armv4t" CPPFLAGS="-I/back/ts/root2/usr/include" 
> LDFLAGS="-L/back/ts/root2/usr/lib/ 
> -L/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib" 
> make
> 
> 
> ...
> /back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
> skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
> /back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
> cannot find /lib/libc.so.6
> collect2: ld returned 1 exit status
> make: *** [pmap_dump] Error 1
> pr
> 
> 
> adding -nostdlib stops it finding the host libc but stops it finding any 
> libc:
> 
> 
>  CFLAGS="-march=armv4t" CPPFLAGS="-I/back/ts/root2/usr/include" 
> LDFLAGS="-L/back/ts/root2/usr/lib/ 
> -L/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib 
> -nostdlib" make
> 
> ...
> 
> /back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
> warning: cannot find entry symbol _start; defaulting to 000080b4
> pmap_dump.o: In function `main':
> pmap_dump.c:(.text+0x28): undefined reference to `memset'
> pmap_dump.c:(.text+0x3c): undefined reference to `htonl'
> pmap_dump.c:(.text+0x4c): undefined reference to `htons'
> pmap_dump.c:(.text+0x60): undefined reference to `pmap_getmaps'
> pmap_dump.c:(.text+0x7c): undefined reference to `getrpcbynumber'
> pmap_dump.c:(.text+0x104): undefined reference to `printf'
> pmap_dump.c:(.text+0x12c): undefined reference to `fclose'
> pmap_dump.c:(.text+0x148): undefined reference to `perror'
> pmap_dump.c:(.text+0x17c): undefined reference to `stdout'
> pmap_dump.o: In function `protoname':
> pmap_dump.c:(.text+0x1d8): undefined reference to `sprintf'
> collect2: ld returned 1 exit status
> make: *** [pmap_dump] Error 1
> 
> 
>  file pmap_dump.o
> pmap_dump.o: ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), not 
> stripped
> 
> 
>  file 
> /back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib/libc.so.6 
> 
> /back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib/libc.so.6: 
> symbolic link to `libc-2.9.so'
> 
> file 
> /back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib/libc-2.9.so 
> 
> /back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib/libc-2.9.so: 
> ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked 
> (uses shared libs), for GNU/Linux 2.6.29, not stripped
> 
> 
> So the two basic issues remain: why does it find /lib/libc.so.6 at all 
> and why can't it find (or use) the library that exists in the libdir 
> explicitly included with -L ??
> 
> 
> This one issue has consumed a lot of time , any help would be appreciated.
> 
> regards, Peter.
> 
> -- 
> For unsubscribe information see http://sourceware.org/lists.html#faq
> 
> 
> 

Hi Yann,

I'll repost this one from last week as a recap since I don't seem to 
have got any closer to the answer.

With help from your I have established with --print-search-dirs that the 
library search path is correct and includes the directory with the 
correct libc.so.6 and does NOT include the host systems /lib.

libraries: 
=/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/lib/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/lib/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/lib/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/lib/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/usr/lib/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/usr/lib/

So why is the linker picking up the host's libc, rejecting it, and than 
failing to find anything else?

The last 10 days has allowed me to confirm that what originally appeared 
to be happening is in fact happening but I am still no closer to 
building this package with crosstool-ng.

The crux of the problem seems to be here:

cat 
/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/usr/lib/libc.so
  /* GNU ld script
      Use the shared library, but some functions are only in
      the static library, so try that secondarily.  */
  OUTPUT_FORMAT(elf32-littlearm)
  GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED (
  /lib/ld-linux.so.3 ) )

 > Yes, correct. Those are paths relative to the sysroot, so gcc will 
hapilly find them.
 > BTW, notice: ld-linux.so.3 -> EABI-era dynamic linker, good.

  rm 
/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/lib/libc.so.6

attempt to open /lib/libc.so.6 succeeded
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6

SO CLEARLY THE INCOMPATIBLE FILE IS THE HOST libc.so.6 NOT THE ARM ONE!

Why is it not using the sys-root one as you suggested it would be?

Thanks.


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

Re: linking correct libc

[ng]

Piotr Borys wrote:
> and what it is saying if you do:
> 
> gcc -print-file-name=libc.so?
> 
> have a look at my recent posts about linking libstdc++...

Hi,

thanks for the reply.

did you mean:

  gcc -print-file-name=libc.so
/usr/lib/gcc/i686-pc-linux-gnu/4.3.3/../../../libc.so

or

  $CC -print-file-name=libc.so
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi//sys-root/usr/lib/libc.so

echo $CC
arm-unknown-linux-gnueabi-gcc


I read your earlier discussion out of general interest but did not note 
anything that seems relevant to my issues. Could you be more specific?

best regards.

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

Re: linking correct libc

[ng]

Yann, anyone? Can't anyone see what is going wrong with the crosstool ld 
here?

I have just compiled gnuplot (an automake ./configure project) and had 
to reinstate the symlink in sys-tools: libc.so.6 -> libc-2.9.so , so 
everything seems to be fine here.

Clearly it is searching the correct directories and NOT in the host's /lib .

So why is it ONLY searching the host's /lib/libc.so.6 when I try to link 
portmap?


Portmap is probably the smallest project I've had to work on but this 
one damn problem has been holding me back for nearly 2 weeks now.

It seems that in interpreting the contents of the arm build's libc.so it 
is taking the reference to /lib/libc.so.6 literally and not in the 
context of a cross-compilation.

What can be making this happen?

regards, Peter.


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

Re: linking correct libc

[Yann E. MORIN]

Peter,
All,

On Tuesday 26 May 2009 09:02:13 ng@piments.com wrote:
> > If it is really an ARM file, you can run again, but setting:
> > LDFLAGS="-L/back/ts/root2/usr/lib/ -v -Wl,--verbose"
[--SNIP--]
> attempt to open /back/ts/root2/usr/lib//libc.so succeeded
> opened script file /back/ts/root2/usr/lib//libc.so
> opened script file /back/ts/root2/usr/lib//libc.so
> attempt to open /lib/libc.so.6 succeeded

Look at that: you've got a libc.so in your root2 tree!
- Where does it come from?
- How did you construct your root2 tree?

The cross-gcc expects to find its libc.so in its sysroot directory (which
it finds automagically). If it finds a libc.so elsewhere, then all its
internal logic is then completelt broken. Remove that file, and see if
it fixes it.

Usually, to build a "rootfs", you'd do something like (replace with adequate
values, obviously!, and iterate for all your packages):
  cd my-package-1
  ./configure --prefix=/usr --build=i686-pc-linux-gnu   \
              --host=arm-unknown-linux-gnueabi          \
              --option1 --option2 [...]
  make
  make install DESTDIR=/back/ts/root2
  cd ..

Once you're done, your root2 will contain all the files installed by your
packages, and only those. It should *not* contain files from the toolchain
(from the syysroot, notably). So it is not suited for direct usage.

You would then use the script provided with crosstool-NG that is specifically
used to complete your root-dir structure with the necessary files:
  arm-unknown-linux-gnueabi-populate -v    \
      -s /back/ts/root2                    \
      -d /back/ts/root2-full

Then, root2-full can be used as input to build file system images for your
target (eg. mksquashfs, mkfs.jffs2and so on...), or can be used as an
NFS-root. Of course, your root2 will still only contain the files installed
by your packages.

This way, you achieve two main goals:
- you don't modify the sysroot, so your toolchain can be reused to build
  other things;
- your root-dir contains only the files installed by the packages, and can
  thus be considered "pure".

Regards,
Yann E. MORIN.

PS. Be patient, if no one answers, it can be for at least two reasons:
- no one has the answer, in which case saying so is just a waste
  of bandwidth;
- someone might have the answer, but is not reading his/her mails
  due to other duties.

Remember, this is a volunteer-based effort, and you can't expect anyone
to abide by your desires. Repeating the same problem again and again
will surely not help.

YEM.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'


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

Re: linking correct libc

[ng]

Yann E. MORIN wrote:
> Peter,
> All,
> 
> On Tuesday 26 May 2009 09:02:13 ng@piments.com wrote:
>>> If it is really an ARM file, you can run again, but setting:
>>> LDFLAGS="-L/back/ts/root2/usr/lib/ -v -Wl,--verbose"
> [--SNIP--]
>> attempt to open /back/ts/root2/usr/lib//libc.so succeeded
>> opened script file /back/ts/root2/usr/lib//libc.so
>> opened script file /back/ts/root2/usr/lib//libc.so
>> attempt to open /lib/libc.so.6 succeeded
> 
> Look at that: you've got a libc.so in your root2 tree!
> - Where does it come from?
> - How did you construct your root2 tree?
> 
THANK YOU! That was the problem. It now compiles fine with ct-ng.

> The cross-gcc expects to find its libc.so in its sysroot directory (which
> it finds automagically). 
I've never been a fan of magic in science and computing. I've always 
found well documented method more reliable ;)

If it finds a libc.so elsewhere, then all its
> internal logic is then completelt broken. 

Well this maybe an area for some simple improvement in the internal 
logic. It clearly knows when it finds something whether it is in 
sys-root or not. If this causes breakage is there any reason not to make 
only search in sys-root or at least display a warning if it picks up 
libc.so somewhere else?

Since I am not familiar with the internal workings of cross-tool I saw 
nothing wrong with it picking up a file in my arm tree. It seemed fine 
to me. I saw no mention of this "magic" sys-root behaviour in the doc so 
I had no reason to think this was a problem.

 > Remove that file, and see if
> it fixes it.
> 
> Usually, to build a "rootfs", you'd do something like (replace with adequate
> values, obviously!, and iterate for all your packages):
>   cd my-package-1
>   ./configure --prefix=/usr --build=i686-pc-linux-gnu   \
>               --host=arm-unknown-linux-gnueabi          \
>               --option1 --option2 [...]
>   make
>   make install DESTDIR=/back/ts/root2
>   cd ..
> 
> Once you're done, your root2 will contain all the files installed by your
> packages, and only those. It should *not* contain files from the toolchain
> (from the syysroot, notably). So it is not suited for direct usage.
> 
> You would then use the script provided with crosstool-NG that is specifically
> used to complete your root-dir structure with the necessary files:
>   arm-unknown-linux-gnueabi-populate -v    \
>       -s /back/ts/root2                    \
>       -d /back/ts/root2-full
> 
> Then, root2-full can be used as input to build file system images for your
> target (eg. mksquashfs, mkfs.jffs2and so on...), or can be used as an
> NFS-root. Of course, your root2 will still only contain the files installed
> by your packages.
> 
> This way, you achieve two main goals:
> - you don't modify the sysroot, so your toolchain can be reused to build
>   other things;
> - your root-dir contains only the files installed by the packages, and can
>   thus be considered "pure".
> 

Thanks I was aware of the process but did not realise ct-ng was intended 
only to create a virgin root fs image or that the presence of some 
library files that are appropriate to the final image could disrupt the 
cross compiler.

Maybe a note on this could be added to the section entitled "using the 
cross-compiler.


> Regards,
> Yann E. MORIN.
> 
> PS. Be patient, if no one answers, it can be for at least two reasons:
> - no one has the answer, in which case saying so is just a waste
>   of bandwidth;
> - someone might have the answer, but is not reading his/her mails
>   due to other duties.
> 
> Remember, this is a volunteer-based effort, and you can't expect anyone
> to abide by your desires. Repeating the same problem again and again
> will surely not help.
> 
> YEM.
> 
I've certainly been patient (and persistent) , I've been working on this 
issue for nearly three weeks.

Rather than repeating the same thing I intended to provide further 
information on the problem and to demonstrate that I had thoroughly 
investigated what was happening.

I'm sure someone with your talents has lots of other duties and I am 
very grateful for your help in finding the cause of this problem.

Cordialement, Peter.





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

Re: linking correct libc

[Yann E. MORIN]

Peter,
All,

On Saturday 30 May 2009 14:06:01 ng@piments.com wrote:
> >> attempt to open /back/ts/root2/usr/lib//libc.so succeeded
> >> opened script file /back/ts/root2/usr/lib//libc.so
> >> opened script file /back/ts/root2/usr/lib//libc.so
> >> attempt to open /lib/libc.so.6 succeeded
> > Look at that: you've got a libc.so in your root2 tree!
> THANK YOU! That was the problem. It now compiles fine with ct-ng.

Good! Sorted, at last! :-)

> Maybe a note on this could be added to the section entitled "using the 
> cross-compiler.

Well, this is standard gcc behavior, and surely I don't want to maintain
a copy of that documentation, as it would eventually drift out of sync
with mainline.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'


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