[crosstool-ng] Small question and mini-patch

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[crosstool-ng] Small question and mini-patch

Joachim Nilsson
Hi!

First I must pay my respects.  Thank you so much for crosstool (Dan) and
thanks for crosstool-ng (Yann) -- totally awsome tool!

Now, the question.  Is it just me or does anyone else find a cross-ldd
tool to be useful for the host?  

A mini-doc-patch for sstrip.in is attached.  It simply adds a bit to the
explanation of the differences between the elfkickers and buildroot
versions.  I.e., the latter supports big-endian systems.

Regards
 /Jocke

Index: config/tools/sstrip.in
===================================================================
--- config/tools/sstrip.in (revision 1028)
+++ config/tools/sstrip.in (working copy)
@@ -18,15 +18,16 @@
     bool
     prompt "ELFkickers"
     help
-      Use the original, ageing version of sstrip from ELFkickers.
-      It seems to be fully functional, but not maintained.
+      The original, ageing version, of sstrip from ELFkickers.
+      Fully functional, but not maintained anymore.
 
 config SSTRIP_BUILDROOT
     bool
     prompt "buildroot"
     help
-      Use the version from buildroot. It comes from the original
-      ELFkickers, but is somewhat maintained by the buildroot guys.
+      Buildroot version, forked off the original from ELFkickers.  This one
+      is somewhat maintained by the buildroot guys.  
+      Supports big-endian systems.
 
 endchoice
 

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

Reply | Threaded
Open this post in threaded view
|

Re: [crosstool-ng] Small question and mini-patch

Yann E. MORIN
Joachim,
All,

On Thursday 25 September 2008 22:22:24 Joachim Nilsson wrote:
> Now, the question.  Is it just me or does anyone else find a cross-ldd
> tool to be useful for the host?  

Do you by chance know how to generate one? ;-)

> A mini-doc-patch for sstrip.in is attached.  It simply adds a bit to the
> explanation of the differences between the elfkickers and buildroot
> versions.  I.e., the latter supports big-endian systems.

Applied, thanks.

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

Reply | Threaded
Open this post in threaded view
|

Re: [crosstool-ng] Small question and mini-patch

Brian Dessent
"Yann E. MORIN" wrote:

> > Now, the question.  Is it just me or does anyone else find a cross-ldd
> > tool to be useful for the host?
>
> Do you by chance know how to generate one? ;-)

ldd is not so much a tool but a wrapper script that simply sets some
environment variables that glibc recognises.  You can achieve the same
effect by e.g. "LD_TRACE_LOADED_OBJECTS=1 command" and instead of
running 'command', glibc will trace what it would have done; see "man
ld.so".

The problem for a cross environment is obvious: you can't execute the
target-glibc, and even if you could it still wouldn't work because it
would expect to search for native paths and not sysroot-ed paths.

To a first approximation you can achieve the same thing by just listing
the DT_NEEDED tags of the binary, e.g. "$target-objdump -p binary | grep
NEEDED" or "$target-readelf -d binary | grep NEEDED".  This will show
you the immediate first-order dependencies of 'binary', but to replicate
what ldd shows you'd have to then recursively apply the same command to
each listed element to compute the full set.

An additional problem is that the NEEDED tag lists just the SONAME,
without a path.  This method completely lacks emulation of the
complicated path searching logic in the dynamic loader, which has to
take into account all the various ways that shared libraries can be
found:

- LD_LIBRARY_PATH environment variable
- DT_RPATH and DT_RUNPATH dynamic tags
- ld.so.conf
- hard-coded system defaults like /usr/lib

So this means that any kind of cross-ldd would have to replicate all of
this, which would be a non-trivial task, but not one that would be
totally impossible.  But I think for the majority of cases you are
really only interested in the first-order dependencies of a program or
library anyway, so it's not necessary.

Brian

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

Reply | Threaded
Open this post in threaded view
|

Re: [crosstool-ng] Small question and mini-patch

Yann E. MORIN
Brian, Joachim, and all,

On Friday 26 September 2008 22:36:38 Brian Dessent wrote:
> > > Now, the question.  Is it just me or does anyone else find a cross-ldd
> > > tool to be useful for the host?
> > Do you by chance know how to generate one? ;-)

I'm afraid I was a little bit ironic... Sorry.

> ldd is not so much a tool but a wrapper script that simply sets some
> environment variables that glibc recognises.
[--SNIP--]
> The problem for a cross environment is obvious: you can't execute the
> target-glibc, and even if you could it still wouldn't work because it
> would expect to search for native paths and not sysroot-ed paths.

Correct. That's not easy.

> To a first approximation you can achieve the same thing by just listing
> the DT_NEEDED tags of the binary, e.g. "$target-objdump -p binary | grep
> NEEDED" or "$target-readelf -d binary | grep NEEDED".  This will show
> you the immediate first-order dependencies of 'binary', but to replicate
> what ldd shows you'd have to then recursively apply the same command to
> each listed element to compute the full set.

The populate script already has some code to do exactly that.

> An additional problem is that the NEEDED tag lists just the SONAME,
> without a path. This method completely lacks emulation of the
> complicated path searching logic in the dynamic loader, which has to
> take into account all the various ways that shared libraries can be
> found:
>
> - LD_LIBRARY_PATH environment variable
> - DT_RPATH and DT_RUNPATH dynamic tags
> - ld.so.conf
> - hard-coded system defaults like /usr/lib

The first three are used to overide default hard-coded paths. BTW, you're
missing LD_PRELOAD, LD_AOUT_PRELOAD and LD_AOUT_LIBRARY_PATH variables, and
the LIB token (dynamic tag?) as well.

What's important is not wether they are set or not, but see below...

> So this means that any kind of cross-ldd would have to replicate all of
> this, which would be a non-trivial task, but not one that would be
> totally impossible.  But I think for the majority of cases you are
> really only interested in the first-order dependencies of a program or
> library anyway, so it's not necessary.

When X-building, it's first important to know if the needed libraries are
going to be in the target file system. Then, where it lies there is not really
meaningful. Let me explain...

Let's take a first example. Your program builds both a .so and an exec linked
againt that .so of yours. Odds are that the install procedure of the program
will just put the .so in a place where the exec can find it (at runtime,
obviously :-) ). If not, then your install procedure is borked.

Next, let's take a more complex example where a library is built from a
package (eg. libz.so) and installed in the root-to-be. Let's assume it is
installed in a standard place (eg. /usr/lib). A second package (your program,
for example) links against that library. At compile time, the linker will
find the library, and at runtime the dynamic linker will also. No problem.

Now let's assume that libz.so is not installed in a standard place. If you
want your program to link against it, you'll have to instruct the linker
where to search for libraries, and because you know that place, you'll be
able to prepare your program to in turn instruct the dynamic loader where
to find it at runtime. No problem.

Trying to use LD_LIBARY_PATH, LD_PRELOAD et al. with the X-ldd is doomed.
There is no way to know wether they are set or not when an executable is
called. (+)

So what a X-ldd should be able to do is to look at all NEEDED and check wether
it can find all the dependencies in the root-to-be, possibly reporting all the
libraries it finds for a single dependency. Bizarely enough, the populate
script already has code to do most of this (except reporting).

Output should ressemble as much as possible that of the native ldd, but
multiple reports would need some special formating, such as:
# ${target}-ldd /target-root-to-be/bin/sh
        linux-vdso.so.1 =>  (0x00007fff04bfe000)                  (*)
        libncurses.so.5 => /lib/libncurses.so.5 (0x00007f73fc6bf000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007f73fc4bb000)
        libc.so.6 => /lib/libc.so.6 (0x00007f73fc168000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f73c1f4c000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f73fc8fe000)
Warning: libc.so.6 resolved multiple times

(*) Note the fake linux-vdso.so dependency, BTW?

I may have missed some corner cases, but hey, it's friday and it's late here.

Regards,
Yann E. MORIN.

(+)
Let's imagine a little shell script that does:
   #!/bin/sh
   var1=LD
   var2=LIBRARY_PATH
   eval export ${var1}_${var2}=/some/place/lib
   exec /your/program

And X-ldd can't know LD_LIBRARY_PATH was set... Doomed, I said... :-]
YEM.

PS. And before any one asks, yes, I can do this silly stuff if pushed
    too hard... :-)
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

Reply | Threaded
Open this post in threaded view
|

Re: [crosstool-ng] Small question and mini-patch

Michael Abbott-4
On Sat, 27 Sep 2008, Yann E. MORIN wrote:
> The populate script already has some code to do exactly that.

That reminds me: I encountered an interesting extra problem using the
populate script: the resolver library (at least in glibc) dynamically
loads the library it requires (unfortunately I can't remember *which*
library that is at the moment) and fails silently if that library can't be
found.  Took me *ages* to figure that one out!

Ah yes, I had to use strace to figure out the problem -- and running it
again, I see that I need to have /lib/libnss_dns.so.2 and
/lib/libresolv.so.2 available.  I don't know why these are always
dynamically linked, seems very odd to me.

Just a little warning if you use this otherwise quite cute script.

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

Reply | Threaded
Open this post in threaded view
|

Re: [crosstool-ng] Small question and mini-patch

Yann E. MORIN
Hello Michael!
Hello All!

On Thursday 02 October 2008 14:05:48 Michael Abbott wrote:
> That reminds me: I encountered an interesting extra problem using the
> populate script: the resolver library (at least in glibc) dynamically
> loads the library it requires (unfortunately I can't remember *which*
> library that is at the moment) and fails silently if that library can't be
> found.  Took me *ages* to figure that one out!

I remember having the same problem... Also took me ages to find out...

> Ah yes, I had to use strace to figure out the problem -- and running it
> again, I see that I need to have /lib/libnss_dns.so.2 and
> /lib/libresolv.so.2 available.  I don't know why these are always
> dynamically linked, seems very odd to me.

Were you linking statically, by chance? Even when building staticaly, you
will need to have the libnss*.so files present. This is called Name Service
Switch, and allows to 'switch' name resolution (hosts, users, groups...)
without recompiling by changing /etc/nsswitch.conf:
  http://www.gnu.org/software/libc/FAQ.html#s-2.22

Not sure it is always usefull to have runtime switch... There are cases
where switching will never ever occur at runtime. There are devices whith
*no* name resolution (yes, there are). But hey, in this case, one might
consider using uClibc instead...

> Just a little warning if you use this otherwise quite cute script.

I was thinking of an additional command line option to populate that
will make it accept a list of forced libraries, eg.:
  ${CT_TARGET}-populate -s dir1 -d dir2 --libs=libnss_{compat,files,dns}-\*.so

Would that help?

Or populate could be smart enough to look at an existing /etc/nsswitch.conf
file, and extract needed nss libraries. Only glibc-based (and eglibc-based)
systems should have /etc/nsswitch.conf.
Of course, it would be the responsibility of the rootfs builder to setup a
proper /etc/nsswitch.conf.

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

Reply | Threaded
Open this post in threaded view
|

Re: [crosstool-ng] Small question and mini-patch

Michael Abbott-4
On Thu, 2 Oct 2008, Yann E. MORIN wrote:
> I was thinking of an additional command line option to populate that
> will make it accept a list of forced libraries, eg.:
>   ${CT_TARGET}-populate -s dir1 -d dir2 --libs=libnss_{compat,files,dns}-\*.so
> Would that help?
Sounds like an interesting thought.

> Or populate could be smart enough to look at an existing /etc/nsswitch.conf
> file, and extract needed nss libraries. Only glibc-based (and eglibc-based)
> systems should have /etc/nsswitch.conf.
> Of course, it would be the responsibility of the rootfs builder to setup a
> proper /etc/nsswitch.conf.

Well now, things become a bit more interesting ... and not really
crosstool territory.  It's rather odd that busybox eschews the rather
tricky business of actually putting together a working system, after
providing (nearly) all the wherewithal.  Arguably populate doesn't belong
in crosstool either, as it's really part of the rootfs builder.

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

Reply | Threaded
Open this post in threaded view
|

Re: [crosstool-ng] Small question and mini-patch

Yann E. MORIN
Michael,
All,

On Thursday 02 October 2008 20:56:19 Michael Abbott wrote:
> On Thu, 2 Oct 2008, Yann E. MORIN wrote:
> > I was thinking of an additional command line option to populate that
> > will make it accept a list of forced libraries, eg.:
> >   ${CT_TARGET}-populate -s dir1 -d dir2 --libs=libnss_{compat,files,dns}-\*.so
> > Would that help?
> Sounds like an interesting thought.

Yep. I will try to have time to look at it...

>  Arguably populate doesn't belong
> in crosstool either, as it's really part of the rootfs builder.

Arguably it is! ;-)

populate is here to complete the rootfs with libraries from the toolchain.
Noone better than crosstool-NG knows where to copy such libraries from, and
thus it is the responsibility of crosstool-NG to provide a utility to retrieve
those libraries.

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

Reply | Threaded
Open this post in threaded view
|

Re: [crosstool-ng] Small question and mini-patch

Joachim Nilsson
In reply to this post by Yann E. MORIN
                                          [RESEND: Due to bounce from ML]
Yann E. MORIN wrote, on 09/26/2008 11:50 AM:
> On Thursday 25 September 2008 22:22:24 Joachim Nilsson wrote:
>> Now, the question.  Is it just me or does anyone else find a cross-ldd
>> tool to be useful for the host?  
> Do you by chance know how to generate one? ;-)

Hi again,

Take a look at the included patch.  It's not the full solution, as have been
discussed previously on this list, but maybe useful to some.

Regards
 /Joachim

Index: scripts/build/libc/uClibc.sh
===================================================================
--- scripts/build/libc/uClibc.sh (revision 1208)
+++ scripts/build/libc/uClibc.sh (working copy)
@@ -143,6 +143,14 @@
          ${CT_LIBC_UCLIBC_VERBOSITY}    \
          install
 
+    # Build and install host-side ldd
+    CT_DoLog EXTRA "Installing C library"
+    CT_DoExecLog ALL                    \
+    make PREFIX="${CT_SYSROOT_DIR}/"    \
+         ${CT_LIBC_UCLIBC_VERBOSITY}    \
+ -C utils hostutils
+    CT_DoExecLog ALL cp utils/ldd.host "${CT_PREFIX_DIR}/bin/${CT_TARGET}"-ldd
+
     CT_EndStep
 }
 


--
For unsubscribe information see http://sourceware.org/lists.html#faq
Reply | Threaded
Open this post in threaded view
|

Re: [crosstool-ng] Small question and mini-patch

Yann E. MORIN
On Sunday 16 November 2008 12:55:33 Joachim Nilsson wrote:
[-- SNIP about cross-ldd --]
> Take a look at the included patch.  It's not the full solution, as have been
> discussed previously on this list, but maybe useful to some.

Nice, should have been obvious! :-)

Thank you!

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

Reply | Threaded
Open this post in threaded view
|

Ubuntu 7.0 crosstool NG

Vivek Kumar Gupta
Hi Yann,
Today I tried the ct-ng-trunk-20081116 on Ubuntu 7.0, and every time it
is not able to get the Linux kernel tar ball in right directory.
When I check download directory there is a soft link created for the
kernel tar ball.
Though same ct-ng-trunk-20081116 was working on Ubuntu 8.0.

I just thought to tell you about this.

Got this error
[DEBUG]    Got 'linux-2.6.26.3' from the Internet
[EXTRA]    Saving 'linux-2.6.26.3' to local storage
[DEBUG]    ==> Executing: 'rm -f
/home/gkvivek/gcc/download/linux-2.6.26.3.tar.bz2'
[DEBUG]    ==> Executing: 'mv -f linux-2.6.26.3.tar.bz2
/home/gkvivek/gcc/download'
[DEBUG]    ==> Executing: 'ln -s
/home/gkvivek/gcc/download/linux-2.6.26.3.tar.bz2
linux-2.6.26.3.tar.bz2'
[DEBUG]    Already have 'gmp-4.2.2'
[DEBUG]    Already have 'mpfr-2.3.1'
[DEBUG]    Already have 'binutils-2.19.50.0.1'
[DEBUG]    Already have 'gcc-4.3.2'
[DEBUG]    Already have 'uClibc-0.9.30'
[INFO ]  Retrieving needed toolchain components' tarballs: done in
1064.53s (at 17:48)
[INFO ]
=================================================================
[INFO ]  Extracting and patching toolchain components
[ERROR]    'linux-2.6.26.3' not found in
'/home/gkvivek/gcc/final/ct-ng-trunk-20081116/targets/tarballs'


Regards
Vivek

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

Reply | Threaded
Open this post in threaded view
|

Crosstool NG on Cygwin(WinXP): ARM922T, GCC 4.3.2, uClibc0.9.30

Vivek Kumar Gupta
Hi All,

I understand it does not work on Cygwin, till I have tried, as I have to
get a tool chain on Windows XP also. Well to my surprise, yes it is
building to good extend.

It is failing in GMP, Kindly see the log in attachment, I will be very
happy if some body can tell where the problem is.


[ALL  ]      CHECK   include/sound/sb16_csp.h
[ALL  ]      CHECK   include/video/edid.h
[ALL  ]      CHECK   include/video/sisfb.h
[ALL  ]      CHECK   include/video/uvesafb.h
[ALL  ]    make[1]: Leaving directory
`/cygdrive/f/cygwin/home/gkvivek/ct-ng-trunk-20081116/targets/src/linux-
2.6.26.3'
[INFO ]  Installing kernel headers: done in 364.48s (at 06:30)
[INFO ]
=================================================================
[INFO ]  Installing GMP
[EXTRA]    Configuring GMP
[DEBUG]    ==> Executing:
'/cygdrive/f/cygwin/home/gkvivek/ct-ng-trunk-20081116/targets/src/gmp-4.
2.2/configure --build=i686-build_unknown-pc-cygwin
--host=i686-build_unknown-pc-cygwin
--prefix=/cygdrive/f/cygwin/home/gkvivek/x-tools/arm-unknown-linux-uclib
c --disable-shared --enable-static --enable-fft --enable-mpbsd'
[ALL  ]    checking build system type... Invalid configuration
`i686-build_unknown-pc-cygwin': machine `i686-build_unknown-pc' not
recognized
[ERROR]    configure: error: /bin/sh
/cygdrive/f/cygwin/home/gkvivek/ct-ng-trunk-20081116/targets/src/gmp-4.2
.2/config.sub i686-build_unknown-pc-cygwin failed
[ERROR]    Build failed in step 'Installing GMP'
[ERROR]    Error happened in
'/opt/ct-ng//lib/ct-ng-1.2.0+svn_trunk@1208/scripts/functions' in
function 'CT_DoExecLog' (line unknown, sorry)
[ERROR]          called from
'/opt/ct-ng//lib/ct-ng-1.2.0+svn_trunk@1208/scripts/build/gmp.sh' at
line # 36 in function 'do_gmp'
[ERROR]          called from
'/opt/ct-ng//lib/ct-ng-1.2.0+svn_trunk@1208/scripts/crosstool.sh' at
line # 481 in function 'main'
[ERROR]    Look at
'/cygdrive/f/cygwin/home/gkvivek/x-tools/arm-unknown-linux-uclibc/build.
log' for more info on this error.
[ERROR]  (elapsed: 6:41.20)



Regards
Vivek

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

build.log (108K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Ubuntu 7.0 crosstool NG

Vivek Kumar Gupta
In reply to this post by Vivek Kumar Gupta
To avoid below said problem I have taken a day old trunk
ct-ng-trunk-20081115.tar.bz2. With this I am able to build the tool
chain, but facing one problem.

I am very much worried about it and looking out for the reason.

"[ERROR]    libtool.m4: error: problem compiling FC test program"

Any one faced this.


Regards
Vivek

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Vivek Kumar Gupta
Sent: Monday, November 17, 2008 2:41 PM
To: [hidden email]
Subject: Ubuntu 7.0 crosstool NG

Hi Yann,
Today I tried the ct-ng-trunk-20081116 on Ubuntu 7.0, and every time it
is not able to get the Linux kernel tar ball in right directory.
When I check download directory there is a soft link created for the
kernel tar ball.
Though same ct-ng-trunk-20081116 was working on Ubuntu 8.0.

I just thought to tell you about this.

Got this error
[DEBUG]    Got 'linux-2.6.26.3' from the Internet
[EXTRA]    Saving 'linux-2.6.26.3' to local storage
[DEBUG]    ==> Executing: 'rm -f
/home/gkvivek/gcc/download/linux-2.6.26.3.tar.bz2'
[DEBUG]    ==> Executing: 'mv -f linux-2.6.26.3.tar.bz2
/home/gkvivek/gcc/download'
[DEBUG]    ==> Executing: 'ln -s
/home/gkvivek/gcc/download/linux-2.6.26.3.tar.bz2
linux-2.6.26.3.tar.bz2'
[DEBUG]    Already have 'gmp-4.2.2'
[DEBUG]    Already have 'mpfr-2.3.1'
[DEBUG]    Already have 'binutils-2.19.50.0.1'
[DEBUG]    Already have 'gcc-4.3.2'
[DEBUG]    Already have 'uClibc-0.9.30'
[INFO ]  Retrieving needed toolchain components' tarballs: done in
1064.53s (at 17:48)
[INFO ]
=================================================================
[INFO ]  Extracting and patching toolchain components
[ERROR]    'linux-2.6.26.3' not found in
'/home/gkvivek/gcc/final/ct-ng-trunk-20081116/targets/tarballs'


Regards
Vivek

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


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

Reply | Threaded
Open this post in threaded view
|

RE: Crosstool NG on Cygwin(WinXP): ARM922T, GCC 4.3.2, uClibc0.9.30

Vivek Kumar Gupta
In reply to this post by Vivek Kumar Gupta
Hi,
I have again taken ct-ng-trunk-20081115.tar.bz2, now it is not able to
patch
boehm-gc/ia64_save_regs_in_stack.S file, is this file needed in all the
systems, like I am using i686 so its different from ia64 m/c. how to
avoid this file from patching.

[DEBUG]    Applying patch
'/opt/ct-ng922t//lib/ct-ng-1.2.0+svn_trunk@1208/patches/gcc/4.3.2/220-no
teGNUstack-01.patch'
[DEBUG]    ==> Executing: 'patch -g0 -F1 -p1 -f'
[ALL  ]    The next patch would create the file
boehm-gc/ia64_save_regs_in_stack.S,
[ALL  ]    which already exists!  Applying it anyway.
[ALL  ]    patching file boehm-gc/ia64_save_regs_in_stack.S
[ALL  ]    Patch attempted to create file
boehm-gc/ia64_save_regs_in_stack.S, which already exists.
[ALL  ]    Hunk #1 FAILED at 1.
[ALL  ]    1 out of 1 hunk FAILED -- saving rejects to file
boehm-gc/ia64_save_regs_in_stack.S.rej
[ALL  ]    patching file boehm-gc/ia64_save_regs_in_stack.s
[ALL  ]    patching file libffi/src/alpha/osf.S
[ALL  ]    patching file libffi/src/arm/sysv.S
[ALL  ]    patching file libffi/src/ia64/unix.S
[ALL  ]    patching file libffi/src/m68k/sysv.S
[ALL  ]    patching file libffi/src/powerpc/linux64.S
[ALL  ]    patching file libffi/src/powerpc/linux64_closure.S
[ALL  ]    patching file libffi/src/powerpc/ppc_closure.S
[ALL  ]    patching file libffi/src/powerpc/sysv.S
[ALL  ]    patching file libffi/src/s390/sysv.S
[ALL  ]    patching file libffi/src/sparc/v8.S
[ALL  ]    patching file libffi/src/sparc/v9.S
[ALL  ]    patching file libffi/src/x86/sysv.S
[ALL  ]    patching file libffi/src/x86/unix64.S
[ERROR]    Build failed in step 'Extracting and patching toolchain
components'
[ERROR]    Error happened in
'/opt/ct-ng922t//lib/ct-ng-1.2.0+svn_trunk@1208/scripts/functions' in
function 'CT_DoExecLog' (line unknown, sorry)
[ERROR]          called from
'/opt/ct-ng922t//lib/ct-ng-1.2.0+svn_trunk@1208/scripts/functions' at
line # 606 in function 'CT_ExtractAndPatch'
[ERROR]          called from
'/opt/ct-ng922t//lib/ct-ng-1.2.0+svn_trunk@1208/scripts/build/cc/gcc.sh'
at line # 25 in function 'do_cc_extract'
[ERROR]          called from
'/opt/ct-ng922t//lib/ct-ng-1.2.0+svn_trunk@1208/scripts/crosstool.sh' at
line # 451 in function 'main'
[ERROR]    Look at '/opt/arm-unknown-linux-uclibc/build.log' for more
info on this error.
[ERROR]  (elapsed: 25:00.46)


Regards
Vivek

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Vivek Kumar Gupta
Sent: Monday, November 17, 2008 3:03 PM
To: [hidden email]
Subject: Crosstool NG on Cygwin(WinXP): ARM922T, GCC 4.3.2, uClibc0.9.30

Hi All,

I understand it does not work on Cygwin, till I have tried, as I have to
get a tool chain on Windows XP also. Well to my surprise, yes it is
building to good extend.

It is failing in GMP, Kindly see the log in attachment, I will be very
happy if some body can tell where the problem is.


[ALL  ]      CHECK   include/sound/sb16_csp.h
[ALL  ]      CHECK   include/video/edid.h
[ALL  ]      CHECK   include/video/sisfb.h
[ALL  ]      CHECK   include/video/uvesafb.h
[ALL  ]    make[1]: Leaving directory
`/cygdrive/f/cygwin/home/gkvivek/ct-ng-trunk-20081116/targets/src/linux-
2.6.26.3'
[INFO ]  Installing kernel headers: done in 364.48s (at 06:30)
[INFO ]
=================================================================
[INFO ]  Installing GMP
[EXTRA]    Configuring GMP
[DEBUG]    ==> Executing:
'/cygdrive/f/cygwin/home/gkvivek/ct-ng-trunk-20081116/targets/src/gmp-4.
2.2/configure --build=i686-build_unknown-pc-cygwin
--host=i686-build_unknown-pc-cygwin
--prefix=/cygdrive/f/cygwin/home/gkvivek/x-tools/arm-unknown-linux-uclib
c --disable-shared --enable-static --enable-fft --enable-mpbsd'
[ALL  ]    checking build system type... Invalid configuration
`i686-build_unknown-pc-cygwin': machine `i686-build_unknown-pc' not
recognized
[ERROR]    configure: error: /bin/sh
/cygdrive/f/cygwin/home/gkvivek/ct-ng-trunk-20081116/targets/src/gmp-4.2
.2/config.sub i686-build_unknown-pc-cygwin failed
[ERROR]    Build failed in step 'Installing GMP'
[ERROR]    Error happened in
'/opt/ct-ng//lib/ct-ng-1.2.0+svn_trunk@1208/scripts/functions' in
function 'CT_DoExecLog' (line unknown, sorry)
[ERROR]          called from
'/opt/ct-ng//lib/ct-ng-1.2.0+svn_trunk@1208/scripts/build/gmp.sh' at
line # 36 in function 'do_gmp'
[ERROR]          called from
'/opt/ct-ng//lib/ct-ng-1.2.0+svn_trunk@1208/scripts/crosstool.sh' at
line # 481 in function 'main'
[ERROR]    Look at
'/cygdrive/f/cygwin/home/gkvivek/x-tools/arm-unknown-linux-uclibc/build.
log' for more info on this error.
[ERROR]  (elapsed: 6:41.20)



Regards
Vivek

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

Reply | Threaded
Open this post in threaded view
|

Re: Crosstool NG on Cygwin(WinXP): ARM922T, GCC 4.3.2, uClibc0.9.30

Yann E. MORIN
In reply to this post by Vivek Kumar Gupta
Vivek,
All,

On Monday 17 November 2008 10:33:27 Vivek Kumar Gupta wrote:
> It is failing in GMP, Kindly see the log in attachment, I will be very
> happy if some body can tell where the problem is.

crosstool-NG mangles the build and host tuples so as to be sure to create
a cross compiler, even when the build and/or host and/or target machines are
of the same kind. Most notably, 3-part tuples are mangled to have a fourth
part added as the vendor string, so as to be coherent throughout the code.
Eg. i686-pc-cygwin -> i686-unknown-pc-cygwin

Unfortunately, that breaks the *-cygwin tuples, that *are* 3-part tuples, and
don't have a vendor part. config.sub does not recognise those tuples as valid
*-cygwin tuples. Sad, but true. Until I have a Windows machine, I can't deal
with that. And I have no plan on having such a beast in the foreseable future.

Still, I will gladly apply correctly argued patches that makes it possible
to build under Cygwin (or any other system by the way!). ;-)

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

Reply | Threaded
Open this post in threaded view
|

Re: Crosstool NG on Cygwin(WinXP): ARM922T, GCC 4.3.2, uClibc0.9.30

Yann E. MORIN
In reply to this post by Vivek Kumar Gupta
Vivek,
All,

On Monday 17 November 2008 15:50:52 Vivek Kumar Gupta wrote:
> I have again taken ct-ng-trunk-20081115.tar.bz2, now it is not able to
> patch
> boehm-gc/ia64_save_regs_in_stack.S file, is this file needed in all the
> systems, like I am using i686 so its different from ia64 m/c. how to
> avoid this file from patching.

I don't know how that can happen. But I'd recommend you get rid of the
targets/ directory and re-run crosstool-NG just to be sure. If it happens
again, there is a problem. If it doesn't, there were some problems whith
initially extracted the sources.

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

Reply | Threaded
Open this post in threaded view
|

Re: [crosstool-ng] Small question and mini-patch

Yann E. MORIN
In reply to this post by Joachim Nilsson
Hello Joachim!
Hello All!

On Sunday 16 November 2008 12:55:33 Joachim Nilsson wrote:
> Take a look at the included patch.  It's not the full solution, as have been
> discussed previously on this list, but maybe useful to some.

Applied with some changes.

Thank you!

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

Reply | Threaded
Open this post in threaded view
|

Re: Crosstool NG on Cygwin(WinXP): ARM922T, GCC 4.3.2, uClibc0.9.30

Carl Miller
In reply to this post by Yann E. MORIN
On Mon, Nov 17, 2008 at 07:34:07PM +0100, Yann E. MORIN wrote:

> Vivek,
> All,
>
> On Monday 17 November 2008 10:33:27 Vivek Kumar Gupta wrote:
> > It is failing in GMP, Kindly see the log in attachment, I will be very
> > happy if some body can tell where the problem is.
>
> crosstool-NG mangles the build and host tuples so as to be sure to create
> a cross compiler, even when the build and/or host and/or target machines are
> of the same kind. Most notably, 3-part tuples are mangled to have a fourth
> part added as the vendor string, so as to be coherent throughout the code.
> Eg. i686-pc-cygwin -> i686-unknown-pc-cygwin
>
> Unfortunately, that breaks the *-cygwin tuples, that *are* 3-part tuples, and
> don't have a vendor part. config.sub does not recognise those tuples as valid
> *-cygwin tuples. Sad, but true.

And I'd agree with it.  In a four-tuple, the third position denotes OS
kernel, and the fourth position denotes OS environment or C library.
"pc" is clearly not an OS kernel.

I'd argue that "i686-pc-cygwin" does indeed have a vendor already.
It's "pc".  What it doesn't have is an OS kernel.  Which can be uniquely
inferred from the OS environment of "cygwin".



                             ------Carl

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

Reply | Threaded
Open this post in threaded view
|

Re: Crosstool NG on Cygwin(WinXP): ARM922T, GCC 4.3.2, uClibc0.9.30

Yann E. MORIN
Hello Carl!
Hello All!

On Monday 17 November 2008 23:06:21 Carl Miller wrote:

> On Mon, Nov 17, 2008 at 07:34:07PM +0100, Yann E. MORIN wrote:
> > Unfortunately, that breaks the *-cygwin tuples, that *are* 3-part tuples, and
> > don't have a vendor part. config.sub does not recognise those tuples as valid
> > *-cygwin tuples. Sad, but true.
>
> And I'd agree with it.  In a four-tuple, the third position denotes OS
> kernel, and the fourth position denotes OS environment or C library.
> "pc" is clearly not an OS kernel.
>
> I'd argue that "i686-pc-cygwin" does indeed have a vendor already.
> It's "pc".  What it doesn't have is an OS kernel.  Which can be uniquely
> inferred from the OS environment of "cygwin".

Which leaves us no choice but to have the mangling done on a
per-{build,host}-OS basis, and not as a generic rule.

Thank you, Carl, for this explanation!

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

Reply | Threaded
Open this post in threaded view
|

CortexM3 GCC 4.3.2

Vivek Kumar Gupta
In reply to this post by Vivek Kumar Gupta
Thanks Yann, for fixing my doubts.

While building tool chain for CortexM3 with GCC 4.3.2, I am getting
error.
Kindly see if this can fix by some way.

I understand that now mcpu is deprecated so I have not used in setting.

When I use Architure level as "armv7m" and Tune for CPU as "cortex-m3"

[ALL  ]    For  real value is
[ALL  ]    For cortex-m3 real value is cortexm3
[ALL  ]    Unknown arch used in --with-arch=armv7m
[ERROR]    make[1]: *** [configure-gcc] Error 1
[ALL  ]    make[1]: Leaving directory
`/newhd/gccCortexM3/ct-ng-trunk-20081115/targets/arm-unknown-linux-uclib
cgnueabi/build/build-cc-core-static'
[ERROR]    Build failed in step 'Installing static core C compiler'


When I use Architure level as "armv7-m" and Tune for CPU as "cortex-m3"

[ALL  ]    For cortex-m3 real value is cortexm3
[ALL  ]    For cortex-m3 real value is cortexm3
[ALL  ]    Unknown arch used in --with-arch=armv7-m
[ERROR]    make[1]: *** [configure-gcc] Error 1
[ALL  ]    make[1]: Leaving directory
`/newhd/gccCortexM3/ct-ng-trunk-20081115/targets/arm-unknown-linux-uclib
cgnueabi/build/build-cc-core-static'

I also tried "armv7m" and "cortexm3" still it is giving error.
I have seen gcc 4.3.2 manual also so according to them right way is
"armv7-m" and cortex-m3"

What extactly I have to use for Architure level  and Tune for CPU ?
Or I have to change some thing else here.


Regards
Vivek

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

12