gdb problem

gdb problem

[Guylhem Aznar]

Hello

The 2nd gdb problem I have and which I can't fix is weird:

(build.log)
x86_64-build_apple-darwin10.8.0-gcc ../objects/tic.o
../objects/dump_entry.o -Wl,-search_paths_first -I../progs
-I/Volumes/Crosstools/crosstool-ng/.build/src/ncurses-5.7/progs
-DHAVE_CONFIG_H
-I/Volumes/Crosstools/crosstool-ng/.build/src/ncurses-5.7/progs/../include
-I. -I../include  -U_XOPEN_SOURCE -D_XOPEN_SOURCE=500 -DSIGWINCH=28
-DNDEBUG -O2 --param max-inline-insns-single=1200  -no-cpp-precomp
-static -L../lib -lncurses -L../lib -lncurses -dynamic   -o tic
[ALL  ]    ld: library not found for -lcrt0.o
[ALL  ]    collect2: ld returned 1 exit status
[ERROR]    make[1]: *** [tic] Error 1
[ERROR]
[ERROR]    >>  Build failed in step 'Installing native gdb'
[ERROR]    >>
[ERROR]    >>  Error happened in: CT_DoExecLog[scripts/functions]

I don't understand why gcc fails with this error now, especially on
tic (part of ncurses) while I asked for a static native gdb.

It is as if it was mistakenly using the host compiler with the target
parameters.

-- 
vCard: http://guylhem.tel

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

Re: gdb problem

[Titus von Boxberg]

Am 17.08.2011 um 22:41 schrieb Guylhem Aznar:

> -static -L../lib -lncurses -L../lib -lncurses -dynamic   -o tic

-static is not supported on Darwin.

Yann, I thought that static linking was disabled now?

Regards
Titus

PS: Why is it building ncurses, anyway?


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

Re: gdb problem

[Yann E. MORIN]

[-- Attachment #1: Type: Text/Plain, Size: 1477 bytes --]

Titus, Guylhem, All,

On Wednesday 17 August 2011 23:31:36 Titus von Boxberg wrote:
> Am 17.08.2011 um 22:41 schrieb Guylhem Aznar:
> 
> > -static -L../lib -lncurses -L../lib -lncurses -dynamic   -o tic
> 
> -static is not supported on Darwin.

Sigh... It slipped through... :-/

> Yann, I thought that static linking was disabled now?

Yes, but no... :-(

> PS: Why is it building ncurses, anyway?

- we need ncurses to build the native gdb that runs on the target.
- we need new-enough version of ncurses.
- ncurses needs tic to build... whatever it need to build.
- tic comes from ncurses
- new-enough ncurses hang when using too-old tic

--> so we need to build out own tic from the same version of ncurses we use
So far, we statically build our tic. As I said above, it slipped through...

Titus, thanks for spotting this.

Guylhem, if you don't really need a native gdb on your target, just disable
it for now. Otherwise, care to test the attached patch?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[-- Attachment #2: ct-ng.debug-gdb-tic-not-static.patch --]
[-- Type: text/x-patch, Size: 753 bytes --]

diff --git a/scripts/build/debug/300-gdb.sh b/scripts/build/debug/300-gdb.sh
--- a/scripts/build/debug/300-gdb.sh
+++ b/scripts/build/debug/300-gdb.sh
@@ -197,7 +197,6 @@
                 --build=${CT_BUILD}                                             \
                 --host=${CT_BUILD}                                              \
                 --prefix=/usr                                                   \
-                --without-shared                                                \
                 --enable-symlinks                                               \
                 --with-build-cc=${CT_REAL_BUILD}-gcc                            \
                 --with-build-cpp=${CT_REAL_BUILD}-gcc                           \


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

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

Re: gdb problem

[Yann E. MORIN]

Titus, Guylhem, All,

On Wednesday 17 August 2011 23:31:36 Titus von Boxberg wrote:
> Am 17.08.2011 um 22:41 schrieb Guylhem Aznar:
> > -static -L../lib -lncurses -L../lib -lncurses -dynamic   -o tic
> -static is not supported on Darwin.
> 
> Yann, I thought that static linking was disabled now?

Well, It seems that -static is somehow hard-coded in ncurses-5.7.
In ./configure we can see starting at line 16481:

  if test "$GCC" = yes ; then
          case $cf_cv_system_name in #(
          OS/2*|os2*|aix[45]*)    #( vi
                  LDFLAGS_STATIC=
                  LDFLAGS_SHARED=
                  ;;
      *)  #( normally, except when broken
          LDFLAGS_STATIC=-static
          LDFLAGS_SHARED=-dynamic
          ;;
      esac
  else
    [--SNIP--]

Here, GCC is set to yes because we are using GNU gcc, and $cf_cv_system_name
is neither OS/2 nor AIX, so we end up in the default case. LDFLAGS_STATIC is
not set later, so it is set to "-static"

Then, in progs/Makefile.in, line 112 (all on one line, split here for
readability:

  LIBS_TIC = @LDFLAGS_STATIC@ @TICS_ARGS@ @TINFO_ARGS@ \
             @LDFLAGS_SHARED@ @LD_MODEL@ @LIBS@

So we see that both LDFLAGS_STATIC *and* LDFLAGS_SHARED are passed when
linking 'tic'. Bummer... :-(

I just looked at ncurses-5.9, and it's the same... :-/

Titus, did you never encountered the issue on your side?

Well, I'll see if it is sane to pass that through sed to remove -static...
Not tonight, though... So, "on your mark" to beat me to it! ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  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: gdb problem

[Guylhem Aznar]

On Thu, Aug 18, 2011 at 18:00, Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> wrote:
> Well, I'll see if it is sane to pass that through sed to remove -static...
> Not tonight, though... So, "on your mark" to beat me to it! ;-)

I'll pass that challenge - I'd like to I don't know enough about
crosstools-ng yet. I want to make it work fine on OSX before starting
to tweak it. As soon as I will be able to properly resume my builds it
will be a good first step :-)

-- 
vCard: http://guylhem.tel

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

Re: gdb problem

[Yann E. MORIN]

Guylhem, All,

On Friday 19 August 2011 04:12:12 Guylhem Aznar wrote:
> On Thu, Aug 18, 2011 at 18:00, Yann E. MORIN
> <yann.morin.1998@anciens.enib.fr> wrote:
> > Well, I'll see if it is sane to pass that through sed to remove -static...
> > Not tonight, though... So, "on your mark" to beat me to it! ;-)
> 
> I'll pass that challenge

In fact, the fix already went in. ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  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: gdb problem

[Titus von Boxberg]

Am 19.08.2011 um 00:32 schrieb Yann E. MORIN:

> Titus, All,
> 
> On Wednesday 17 August 2011 23:31:36 Titus von Boxberg wrote:
>> -static is not supported on Darwin.
> 
> So -static is not supported on Darwin? So why on Earth does the ncurses from
> Macports install static versions of the libraries?
Passing -static is not equivalent to linking to an archive file.

http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/ld.1.html

> Darwin really, really is a *PITA*. Sigh... Taking so nice and slick a
> kernel, and putting that much sh*t ontop of it is purely bullshit to
> me... Sorry, but I'm tired of that crap... :-(
That from someone who develops a large software collection only to work
around a really BIG pile of crap ;-) Hey, did you forget what ct-ng is
actually doing and what it's for?

Anyway:
Could writing emails past midnight be a major reason for your exhaustion,
not to speak of other abdominal problems you might currently suffer from,
or is this a final statement about portability of ct-ng?

If the former, then why not simply tackle those problems and add a fix?
Guylhem, mind to send me again your most current .config.
I'd give it a try on the weekend.

If the latter, then leave it as is.

Regards
Titus


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

Re: gdb problem

[Guylhem Aznar]

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

Hello

On Fri, Aug 19, 2011 at 03:09, Titus von Boxberg <titus@v9g.de> wrote:
> If the former, then why not simply tackle those problems and add a fix?

It might be complicated without a platform to test - the reason why I
offered to put a mac online to try to compile.

> Guylhem, mind to send me again your most current .config.
> I'd give it a try on the weekend.

Here is one which work with the uclibc find fixes, and which I am
uploading and announcing on my blog (en.blog.guylhem.net)
You can get them on:
http://dl.dropbox.com/u/984275/fritzbox/Crosstools.dmg.bz2 and
http://dl.dropbox.com/u/984275/fritzbox/Fritzbox.dmg.bz2

It is incomplete however (see "still getting errors" message : no
gdb/gdbserver, no ltrace)

Some notes :
 CT_DEBUG_PAUSE_STEPS and CT_DEBUG_CT_SAVE_STEPS have been disabled
because I don't understand how to resume a build - with or without
them, it just fails.
 CT_GDB_V_6_8 has been disabled. It would have been nice to run gdb
and gdbserver on the mips target, but it cause the tic static bug, and
the tree.ref bug to appear
 CT_LTRACE_V_0_5_3 has been disabled due to make not finding a file
called "Darwin"

Maybe you could try to enable one on more of these options to fix the
remaining bugs? (the build resuming thing might not be a bug, just a
misunderstanding on my part)

BTW - would it be possible to use a uclibc 0.9.29 with the current
crosstools-ng release? I have had problems with some binaries compiled
for 0.9.30, so at the moment I'm compiling everything static. The
target for which I'm preparing a cross toolchain use this very 0.9.29
version in the default international firmware, which is very popular
in Australia.

-- 
vCard: http://guylhem.tel

[-- Attachment #2: config.bz2 --]
[-- Type: application/x-bzip2, Size: 2401 bytes --]

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

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

compiling ltrace on macos / was Re: gdb problem

[Titus von Boxberg]

Am 19.08.2011 um 20:58 schrieb Guylhem Aznar:
> On Fri, Aug 19, 2011 at 03:09, Titus von Boxberg <titus@v9g.de> wrote:
>> Guylhem, mind to send me again your most current .config.
>> I'd give it a try on the weekend.
> 
> Here is one which work with the uclibc find fixes, and which I am
Guylhem, Yann,

with the recent patch series I'm able to build your mips config
with the following changes:
- did not have your files: linux kernel tarball, uclibc config file, so:
  - used the uClibc-0.9.30 config file from samples directory
  - used CT_KERNEL_V_2_6_35_14
- enabled gdb6.8 with static gdbserver

> CT_LTRACE_V_0_5_3 has been disabled due to make not finding a file
> called "Darwin"
I tried to compile ltrace. It suffers from
- configuring HOST_OS to be "Darwin".
- archive index (ranlib) missing in libltrace.a
- archive index (ranlib) missing in sys-root/usr/lib/libelf.a
- missing index(3) during linking of ltrace:
  read_config_file.c:86: undefined reference to `index'.

The first three would be fairly simple to correct.
As a uclibc-agnostic, the last one is beyond my imagination.
Any hints?

Regards
Titus


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

Re: compiling ltrace on macos / was Re: gdb problem

[Guylhem Aznar]

Hello

On Sun, Aug 21, 2011 at 11:48, Titus von Boxberg <titus@v9g.de> wrote:
> with the recent patch series I'm able to build your mips config
> with the following changes:
> - did not have your files: linux kernel tarball, uclibc config file, so:

As announced, "It is now available online as a DMG on
http://dl.dropbox.com/u/984275/fritzbox/Fritzbox.dmg.bz2, along with
the source code that was used to produce it :
http://dl.dropbox.com/u/984275/fritzbox/Crosstools.dmg.bz2."

>  - used the uClibc-0.9.30 config file from samples directory
>  - used CT_KERNEL_V_2_6_35_14

Both are in Fritzbox.dmg.bz2

>  read_config_file.c:86: undefined reference to `index'.
> The first three would be fairly simple to correct.
> As a uclibc-agnostic, the last one is beyond my imagination.
> Any hints?

In my "handy functions" .h, which I frequently use to compile with uclibc :
#define MAX_LINE 255
#define getwd(x) getcwd(x,MAX_LINE)
#define bcmp(s1,s2,n) memcmp((s1), (s2), (size_t)(n))
#define index(s,c) strchr((s), (c))
#define rindex(s,c) strrchr((s), (c))
#define bcopy(src, dst, len) memcpy(dst, src, len)

Guylhem

-- 
vCard: http://guylhem.tel

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

Re: compiling ltrace on macos / was Re: gdb problem

[Titus von Boxberg]

Am 21.08.2011 um 20:11 schrieb Guylhem Aznar:
>>  read_config_file.c:86: undefined reference to `index'.
>> The first three would be fairly simple to correct.
>> As a uclibc-agnostic, the last one is beyond my imagination.
>> Any hints?
> 
> In my "handy functions" .h, which I frequently use to compile with uclibc :
> #define MAX_LINE 255
> #define getwd(x) getcwd(x,MAX_LINE)
> #define bcmp(s1,s2,n) memcmp((s1), (s2), (size_t)(n))
> #define index(s,c) strchr((s), (c))
> #define rindex(s,c) strrchr((s), (c))
> #define bcopy(src, dst, len) memcpy(dst, src, len)
Yann, Guylhem,

I'm just wondering if (and how!) uclibc/ltrace ever has been used before.
Since I do not use both, I'm reluctant to change it, though
replacing index by strchr doesn't look too difficult.

Comments?
Regards

Titus


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

Re: gdb problem

[Guylhem Aznar]

Hello

On Fri, Aug 19, 2011 at 03:09, Titus von Boxberg <titus@v9g.de> wrote:
> If the former, then why not simply tackle those problems and add a fix?

It might be complicated without a platform to test - the reason why I
offered to put a mac online to try to compile.

> Guylhem, mind to send me again your most current .config.
> I'd give it a try on the weekend.

Here is one which work with the uclibc find fixes, and which I will
release soon. It is incomplete however (see "still getting errors"
message : no gdb/gdbserver, no strace)

Some notes :
 CT_DEBUG_PAUSE_STEPS and CT_DEBUG_CT_SAVE_STEPS have been disabled
because I don't understand how to resume a build - with or without
them, it just fails.
 CT_GDB_V_6_8 has been disabled. It would have been nice to run gdb
and gdbserver on the mips target, but it cause the tic static bug, and
the tree.ref bug to appear
 CT_LTRACE_V_0_5_3 has been disabled due to make not finding a file
called "Darwin"

Maybe you could try to enable one on more of these options to fix the
remaining bugs? (the build resuming thing might not be a bug, just a
misunderstanding on my part)

BTW - would it be possible to use a uclibc 0.9.29 with the current
crosstools-ng release? the target for which I'm preparing a cross
toolchain use this very version. I have had problems with some
binaries compiled for 0.9.30, so at the moment I'm compiling
everything static.

-- 
vCard: http://guylhem.tel

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

Re: gdb problem

[Titus von Boxberg]

Am 19.08.2011 um 20:00 schrieb Yann E. MORIN:

> Titus, All,
> 
> On Friday 19 August 2011 09:09:27 Titus von Boxberg wrote:
>> Am 19.08.2011 um 00:32 schrieb Yann E. MORIN:
>>> On Wednesday 17 August 2011 23:31:36 Titus von Boxberg wrote:
>>>> -static is not supported on Darwin.
>>> 
>>> So -static is not supported on Darwin? So why on Earth does the ncurses from
>>> Macports install static versions of the libraries?
>> Passing -static is not equivalent to linking to an archive file.
> 
> I know, but it seems to me that creating static libraries is possible on
> Darwin, and thus there would be a way to ask for staticaly linking an
> executable.
There are 3 things intermixed here.
1) You can link to static libraries.
E.g. my software is built as static libs.
No problem to link them in. But see below.

2) You cannot produce a statically linked executable.
Actually, I do not know exactly why that is the case,
viewed on Mach-O bit level (and strange enough, that
lack of knowledge doesn't bother me ;-).
You always have to produce an executable that requires
the dynamic linker/loader combo to start a process from it.
Or the other way round: no program can be started without
the dynamic linker/loader.

3)
A third thing comes in from this particular problem:
you cannot select a static lib when a dynamic lib is found
in the same path.
You have to play tricks to get that done, as given in
http://developer.apple.com/library/mac/#qa/qa1393/_index.html

From `man ld`, and points 1) and 3) above results that the elf-ld
compatible command line … -static -lnicelib -dynamic -lblah … does not work.

The only ways to achieve the equivalent of this command line
would be to ensure that
- libnicelib is present only as an archive file but not as a dylib, or
- the linker search paths are made up as outlined in Apple's reference.

In short: Drop the idea of static linking as completely as possible on Darwin.
Time's a too precious resource for that crap.

> No, absolutely not. I'll learn to post-pone such mails in the future, so
> I can be in a more relaxed state before I post. Apologies to anyone who
> might have resenseted offense…
No offense taken. I just wanted to know whether you are restricting
ct-ng to Linux.

> 
>> If the former, then why not simply tackle those problems and add a fix?
> 
> Sure, sure. It's just that I am a bit lost here, as I do not have the
> slightest idea on how we should do things on Darwin.
?? The things I tested worked very well. No need to be pessimistic.
As I wrote early 2010, compared to old crosstool and earlier tool chains,
things went very smoothly and the patches necessary for BSD/Darwin
were ridiculously small.

Darwin, may it be idiosyncratic in this or the other way, still is a
UNIX compliant system.

I never tried uclibc, so I'm not surprised that problems arise.

In general (not only for Darwin) I'd say:
Try to be as much UNIX/Posix compliant as possible.
Do not use the more or less unnecessary GNU extensions.
At least within ct-ng this rule can be easily followed.
Where the problems following this rule outweigh the benefit,
add the GNU tool as a prerequisite.

> 
> On the one hand, I'd rather not have ugly kludges in the code to handle
> Darwin, or we could see a proliferation of those kludges, not only for
> Darwin, but also other OSes. Think Cygwin and mingw for example, which
> have their own idiosyncracies and limitations in their own subtle ways.
What is a kludge, here? You can also view it the other way round.
If you use nonportable features of one platform (like static linking)
then this might be regarded as a kludge (just like I still regard it in this
particular case). After all, if I remember correctly, you introduced static linking
because you fear that (libstd)c++ undergoes ABI changes and the Linux distros
cannot handle that (which I feel is an absolutely legitimate concern,
nonetheless all this is an Evil Kludge from GNU Hell).


> On the other hand, I'd like to have support for as many systems as
> possible (World Domination, anyone? ;-)), while not being capable or
> able to get my hands on said systems.
I'm afraid that even World Domination has to be gained in small steps.
divide et impera.
For continuous support of host OSs other than linux, here Darwin,
I'd recommend that there is a set of configs identified
that are expected to work on that OS / Darwin.

I could add mine to that set.

Maybe rename samples directory into "samples-linuxhost", and
add other samples directories for the particular host OSs.

We already know (and Guylhem just experienced) the build
systems of the tool chain parts are only portable to a certain extent.

Introducing a host OS specific set of working examples
would mean that one cannot expect to have ct-ng
build any tool chain combination (in the general/linux samples directory)
out of the box on non-GNU/Linux systems, but there is at
least a (smaller) starting point the user can rely upon.

How do you handle it now with older configs that eventually break
on newer Linux host systems? Or with now more or less unsupported things
like OABI for ARM? Do you silently delete the samples as the older tool chain
parts get dropped from menuconfig?
Or just add a "deprecated/broken" note? Do you drop anything at all?

Just do it the other way round for Darwin/other OSs.

Furthermore, you might also add patches directories specific
to the host OS; then maybe patches (like mine for eglibc,
or the coming ones for uclibc) could be introduced more quickly
because there is no danger that things get broken on Linux.



Do you have scripts for regular automatic tests of the samples?
Then - if the tool chains working on Darwin are identified -
testing at least the build steps (omitting menuconfig et.al.)
could be done automatically.
Just an idea.


Anyway, Guylhem sent me his .config.
I'll try the next days to get things to work.

Regards
Titus


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