egcs 1.1.2 vs. HP/UX 10.20

egcs 1.1.2 vs. HP/UX 10.20

[Stephen Walton]

I followed the advice in INSTALL and put binutils 2.9 on my HP/UX 10.20
system before attempting to build.  Even though /usr/local/bin is first
in my search path, and gas is installed there ("which as" returns
/usr/local/bin/as, and "as --version" returns 2.9), it doesn't get used
on "make bootstrap".  I ran "configure" with no arguments.  I can finish
up with "make all" and could install what I have, but would like to have
everything working properly first.  Advice?

--
Stephen Walton, Professor of Physics and Astronomy,
California State University, Northridge
stephen.walton@csun.edu

Re: egcs 1.1.2 vs. HP/UX 10.20

[Jeffrey A Law]

  In message < Pine.LNX.4.04.9904082118420.494-100000@pm3o-30.pacificnet.net >you
 write:
  > I followed the advice in INSTALL and put binutils 2.9 on my HP/UX 10.20
  > system before attempting to build.  Even though /usr/local/bin is first
  > in my search path, and gas is installed there ("which as" returns
  > /usr/local/bin/as, and "as --version" returns 2.9), it doesn't get used
  > on "make bootstrap".  I ran "configure" with no arguments.  I can finish
  > up with "make all" and could install what I have, but would like to have
  > everything working properly first.  Advice?
What precisely do you mean by "doesn't get used"?

It sounds like you did not _configure_ gcc to use gas by default.  In that
case you will get messages like "-g is only supported when using GAS ..."
because the default code generation will assume that you will not always be
using the GNU assembler.

ie, that message has absolutely nothing to do with whether or not gas is
found in your path.  It is strictly based on how you configured gcc.

You can use the configure option "--with-gnu-as" to tell gcc that it
should expect the GNU assembler will be used to assemble code produced by
gcc.

It sounds like that's the only problem you've got -- based on your other
comments, I believe gcc will find gas without any problems.


jeff

Re: egcs 1.1.2 vs. HP/UX 10.20

[Jeffrey A Law]

  In message < Pine.LNX.4.04.9904082118420.494-100000@pm3o-30.pacificnet.net >you
 write:
  > I followed the advice in INSTALL and put binutils 2.9 on my HP/UX 10.20
  > system before attempting to build.  Even though /usr/local/bin is first
  > in my search path, and gas is installed there ("which as" returns
  > /usr/local/bin/as, and "as --version" returns 2.9), it doesn't get used
  > on "make bootstrap".  I ran "configure" with no arguments.  I can finish
  > up with "make all" and could install what I have, but would like to have
  > everything working properly first.  Advice?
What precisely do you mean by "doesn't get used"?

It sounds like you did not _configure_ gcc to use gas by default.  In that
case you will get messages like "-g is only supported when using GAS ..."
because the default code generation will assume that you will not always be
using the GNU assembler.

ie, that message has absolutely nothing to do with whether or not gas is
found in your path.  It is strictly based on how you configured gcc.

You can use the configure option "--with-gnu-as" to tell gcc that it
should expect the GNU assembler will be used to assemble code produced by
gcc.

It sounds like that's the only problem you've got -- based on your other
comments, I believe gcc will find gas without any problems.


jeff

egcs 1.1.2 vs. HP/UX 10.20

[Stephen Walton]

I followed the advice in INSTALL and put binutils 2.9 on my HP/UX 10.20
system before attempting to build.  Even though /usr/local/bin is first
in my search path, and gas is installed there ("which as" returns
/usr/local/bin/as, and "as --version" returns 2.9), it doesn't get used
on "make bootstrap".  I ran "configure" with no arguments.  I can finish
up with "make all" and could install what I have, but would like to have
everything working properly first.  Advice?

--
Stephen Walton, Professor of Physics and Astronomy,
California State University, Northridge
stephen.walton@csun.edu

Re: egcs 1.1.2 vs. HP/UX 10.20

[Marc Girod]

>>>>> "SW" == Stephen Walton <swalton@pacificnet.net> writes:

SW> I followed the advice in INSTALL and put binutils 2.9 on my HP/UX 10.20
SW> system before attempting to build.  Even though /usr/local/bin is first
SW> in my search path, and gas is installed there ("which as" returns
SW> /usr/local/bin/as, and "as --version" returns 2.9), it doesn't get used
SW> on "make bootstrap".  I ran "configure" with no arguments.  I can finish
SW> up with "make all" and could install what I have, but would like to have
SW> everything working properly first.  Advice?

I did manage to build egcs 1.1.2 for HP-UX 10.20 with binutils, and I
know what you mean: in practice, binutils must be installed first _in
the directory_ in which you install egcs (i.e. deduced from your
prefix setting).

For me, it meant:

/tools/contrib/HP-UX/B.10.20/hppa1.1/packages/egcs/lib/gcc-lib/hppa1.1-hp-hpux10.20/egcs-2.91.66

as my prefix was:

/tools/contrib/HP-UX/B.10.20/hppa1.1/packages/egcs

The egcs installation will silently ignore:

- your path
- any setting through --with-gnu-as=xxx and the like.

They are (I believe) a few other hard-coded canonic directories which
are searched, but they didn't match in my case.

Note that my gas is 2.9.1.

An other note: I also have DCE threads installed, and egcs makes use
of them, with the result that any linking with gcc needs to be passed
the -ldce option.

I already reported the first issue (without managing to convince the
maintainers that it was a problem), but not this second, should I?

Best Regards!
Marc

-- 
Marc Girod                Hiomo 5/1          Voice:  +358-9-511 23746
Nokia Telecommunications  P.O. Box 320       Mobile: +358-40-569 7954
NWS/NMS/NMS for Data      00045 NOKIA Group  Fax:    +358-9-511 23580
                          Finland            marc.girod@ntc.nokia.com

Re: egcs 1.1.2 vs. HP/UX 10.20

[Jeffrey A Law]

  In message < 1yemlunyiq.fsf@mahtan.ntc.nokia.com >you write:
  > An other note: I also have DCE threads installed, and egcs makes use
  > of them, with the result that any linking with gcc needs to be passed
  > the -ldce option.
Yes.

  > I already reported the first issue (without managing to convince the
  > maintainers that it was a problem), but not this second, should I?
It's an issue, we just don't have a good solution.   If you've got one
I'd love to hear it.

jeff

Re: egcs 1.1.2 vs. HP/UX 10.20

[Jeffrey A Law]

  In message < 1yemlunyiq.fsf@mahtan.ntc.nokia.com >you write:
  > An other note: I also have DCE threads installed, and egcs makes use
  > of them, with the result that any linking with gcc needs to be passed
  > the -ldce option.
Yes.

  > I already reported the first issue (without managing to convince the
  > maintainers that it was a problem), but not this second, should I?
It's an issue, we just don't have a good solution.   If you've got one
I'd love to hear it.

jeff

Re: egcs 1.1.2 vs. HP/UX 10.20

[Marc Girod]

>>>>> "SW" == Stephen Walton <swalton@pacificnet.net> writes:

SW> I followed the advice in INSTALL and put binutils 2.9 on my HP/UX 10.20
SW> system before attempting to build.  Even though /usr/local/bin is first
SW> in my search path, and gas is installed there ("which as" returns
SW> /usr/local/bin/as, and "as --version" returns 2.9), it doesn't get used
SW> on "make bootstrap".  I ran "configure" with no arguments.  I can finish
SW> up with "make all" and could install what I have, but would like to have
SW> everything working properly first.  Advice?

I did manage to build egcs 1.1.2 for HP-UX 10.20 with binutils, and I
know what you mean: in practice, binutils must be installed first _in
the directory_ in which you install egcs (i.e. deduced from your
prefix setting).

For me, it meant:

/tools/contrib/HP-UX/B.10.20/hppa1.1/packages/egcs/lib/gcc-lib/hppa1.1-hp-hpux10.20/egcs-2.91.66

as my prefix was:

/tools/contrib/HP-UX/B.10.20/hppa1.1/packages/egcs

The egcs installation will silently ignore:

- your path
- any setting through --with-gnu-as=xxx and the like.

They are (I believe) a few other hard-coded canonic directories which
are searched, but they didn't match in my case.

Note that my gas is 2.9.1.

An other note: I also have DCE threads installed, and egcs makes use
of them, with the result that any linking with gcc needs to be passed
the -ldce option.

I already reported the first issue (without managing to convince the
maintainers that it was a problem), but not this second, should I?

Best Regards!
Marc

-- 
Marc Girod                Hiomo 5/1          Voice:  +358-9-511 23746
Nokia Telecommunications  P.O. Box 320       Mobile: +358-40-569 7954
NWS/NMS/NMS for Data      00045 NOKIA Group  Fax:    +358-9-511 23580
                          Finland            marc.girod@ntc.nokia.com

Re: egcs 1.1.2 vs. HP/UX 10.20

[Marc Girod]

>>>>> "JL" == Jeffrey A Law <law@upchuck.cygnus.com> writes:

>> An other note: I also have DCE threads installed, and egcs makes use
>> of them, with the result that any linking with gcc needs to be passed
>> the -ldce option.

JL> It's an issue, we just don't have a good solution.   If you've got one
JL> I'd love to hear it.

% nm++ libgcc.a | grep pthread
pthread_getspecific |          |undef |code   |
pthread_keycreate   |          |undef |code   |
pthread_once        |          |undef |code   |
pthread_setspecific |          |undef |code   |

But none of the objects in gcc or gcc/cp seems to have any of these
symbols?! Ahum... I miss something.

Looking at the transcript, libgcc.a is built from objects which are
removed after being archived in a temporary libgcc2.a, is this the
reason I cannot find them?

If you can tell how I can easily reproduce them, I'd be happy to
investigate which one pulls in the DCE symbols.

Best Regards!
Marc

-- 
Marc Girod                Hiomo 5/1          Voice:  +358-9-511 23746
Nokia Telecommunications  P.O. Box 320       Mobile: +358-40-569 7954
NWS/NMS/NMS for Data      00045 NOKIA Group  Fax:    +358-9-511 23580
                          Finland            marc.girod@ntc.nokia.com

Re: egcs 1.1.2 vs. HP/UX 10.20

[Jeffrey A Law]

  In message < 1y90bpsovo.fsf@mahtan.ntc.nokia.com >you write:
  > % nm++ libgcc.a | grep pthread
  > pthread_getspecific |          |undef |code   |
  > pthread_keycreate   |          |undef |code   |
  > pthread_once        |          |undef |code   |
  > pthread_setspecific |          |undef |code   |
Yes.  They are referenced by the MT thread safe exception handling code.

  > But none of the objects in gcc or gcc/cp seems to have any of these
  > symbols?! Ahum... I miss something.
Correct.  They must be provided by the system thread libraries.

jeff

Re: egcs 1.1.2 vs. HP/UX 10.20

[Jeffrey A Law]

  In message < 1y90bpsovo.fsf@mahtan.ntc.nokia.com >you write:
  > % nm++ libgcc.a | grep pthread
  > pthread_getspecific |          |undef |code   |
  > pthread_keycreate   |          |undef |code   |
  > pthread_once        |          |undef |code   |
  > pthread_setspecific |          |undef |code   |
Yes.  They are referenced by the MT thread safe exception handling code.

  > But none of the objects in gcc or gcc/cp seems to have any of these
  > symbols?! Ahum... I miss something.
Correct.  They must be provided by the system thread libraries.

jeff

Re: egcs 1.1.2 vs. HP/UX 10.20

[Marc Girod]

>>>>> "JL" == Jeffrey A Law <law@upchuck.cygnus.com> writes:

>> An other note: I also have DCE threads installed, and egcs makes use
>> of them, with the result that any linking with gcc needs to be passed
>> the -ldce option.

JL> It's an issue, we just don't have a good solution.   If you've got one
JL> I'd love to hear it.

% nm++ libgcc.a | grep pthread
pthread_getspecific |          |undef |code   |
pthread_keycreate   |          |undef |code   |
pthread_once        |          |undef |code   |
pthread_setspecific |          |undef |code   |

But none of the objects in gcc or gcc/cp seems to have any of these
symbols?! Ahum... I miss something.

Looking at the transcript, libgcc.a is built from objects which are
removed after being archived in a temporary libgcc2.a, is this the
reason I cannot find them?

If you can tell how I can easily reproduce them, I'd be happy to
investigate which one pulls in the DCE symbols.

Best Regards!
Marc

-- 
Marc Girod                Hiomo 5/1          Voice:  +358-9-511 23746
Nokia Telecommunications  P.O. Box 320       Mobile: +358-40-569 7954
NWS/NMS/NMS for Data      00045 NOKIA Group  Fax:    +358-9-511 23580
                          Finland            marc.girod@ntc.nokia.com

Re: egcs 1.1.2 vs. HP/UX 10.20

[Marc Girod]

>>>>> "JL" == Jeffrey A Law <law@upchuck.cygnus.com> writes:

>> An other note: I also have DCE threads installed, and egcs makes use
>> of them, with the result that any linking with gcc needs to be passed
>> the -ldce option.

JL> It's an issue, we just don't have a good solution.   If you've got one
JL> I'd love to hear it.

The dce symbols come (at least) from the object file _eh.o, archived
into libgcc2.a (and from there to libgcc.a).

It is compiled from gcc/libgcc2.c with the command:

./xgcc -B./ -B/tools/contrib/HP-UX/B.10.20/hppa2.0/packages/egcs/hppa2.0-hp-hpux10.20/bin/ -O2   -DIN_GCC -DHAIFA    -g -W -Wall -I./include  -fPIC -g1 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -fexceptions -I. -I. -I./config -I./../include -c \
      -DL${name} ./libgcc2.c -o _eh.o

In file included from gthr-default.h:1,
                 from gthr.h:98,
                 from ./libgcc2.c:3025:
gthr-dce.h: In function `__gthread_key_dtor':
gthr-dce.h:95: warning: unused parameter `key'
gthr-dce.h:95: warning: unused parameter `ptr'
gthr-dce.h: In function `__gthread_key_delete':
gthr-dce.h:104: warning: implicit declaration of function `pthread_key_delete'

Indeed, gthr-default.h includes gthr-dce.h, which #defines __GTHREADS
and includes pthread.h...

Isn't it so that one would want to define -DHAVE_GTHR_DEFAULT _only_
when building gcc/threads/libgcc.a (_not_ when building gcc/libgcc.a)?

Note: this is true as well with egcs-2.93.21 (ss-19990502).



Also, when debugging a file compiled with egcs on HP-UX 10.20, gdb
complains of the following:

warning: Unable to find __d_pid symbol in object file.
warning: Suggest linking with /opt/langtools/lib/end.o.
warning: GDB will be unable to track shl_load/shl_unload calls

This means that the c++ driver fails to, parsing the -g flag, add the
/opt/langtools/lib/end.o file as the last file named on the link line.

Indeed:

% nm++ /opt/langtools/lib/end.o | grep __d_pid
__d_pid             |1073745992|extern|data   |$SHORTDATA$


Best Regards!
Marc

-- 
Marc Girod                Hiomo 5/1          Voice:  +358-9-511 23746
Nokia Telecommunications  P.O. Box 320       Mobile: +358-40-569 7954
NWS/NMS/NMS for Data      00045 NOKIA Group  Fax:    +358-9-511 23580
                          Finland            marc.girod@ntc.nokia.com

Re: egcs 1.1.2 vs. HP/UX 10.20

[Jeffrey A Law]

  In message < 1yaevlotru.fsf@anvil.ntc.nokia.com >you write:
  > The dce symbols come (at least) from the object file _eh.o, archived
  > into libgcc2.a (and from there to libgcc.a).
Yes.  This is what I would expect.

  > It is compiled from gcc/libgcc2.c with the command:
  > 
  > ./xgcc -B./ -B/tools/contrib/HP-UX/B.10.20/hppa2.0/packages/egcs/hppa2.0-hp
  > -hpux10.20/bin/ -O2   -DIN_GCC -DHAIFA    -g -W -Wall -I./include  -fPIC -g
  > 1 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -fexceptions 
  > -I. -I. -I./config -I./../include -c \
  >       -DL${name} ./libgcc2.c -o _eh.o
  > 
  > In file included from gthr-default.h:1,
  >                  from gthr.h:98,
  >                  from ./libgcc2.c:3025:
  > gthr-dce.h: In function `__gthread_key_dtor':
  > gthr-dce.h:95: warning: unused parameter `key'
  > gthr-dce.h:95: warning: unused parameter `ptr'
  > gthr-dce.h: In function `__gthread_key_delete':
  > gthr-dce.h:104: warning: implicit declaration of function `pthread_key_dele
  > te'
  > 
  > Indeed, gthr-default.h includes gthr-dce.h, which #defines __GTHREADS
  > and includes pthread.h...
  > 
  > Isn't it so that one would want to define -DHAVE_GTHR_DEFAULT _only_
  > when building gcc/threads/libgcc.a (_not_ when building gcc/libgcc.a)?
Unsure.  The C++ people would have to chime in.  I don't do C++, threads or
exceptions :-)


  > Also, when debugging a file compiled with egcs on HP-UX 10.20, gdb
  > complains of the following:
  > 
  > warning: Unable to find __d_pid symbol in object file.
  > warning: Suggest linking with /opt/langtools/lib/end.o.
  > warning: GDB will be unable to track shl_load/shl_unload calls
What version of gdb?  Whatever it is it pre-dates support for debugging
dynamic objects on hpux10 and is very old (since I fixed this problem at
least 2 years ago).

Linking in end.o on hpux10 is highly undesirable.  If you attempt to do
so you'll find that your program will not link.

jeff

Re: egcs 1.1.2 vs. HP/UX 10.20

[Jeffrey A Law]

  In message < 1yaevlotru.fsf@anvil.ntc.nokia.com >you write:
  > The dce symbols come (at least) from the object file _eh.o, archived
  > into libgcc2.a (and from there to libgcc.a).
Yes.  This is what I would expect.

  > It is compiled from gcc/libgcc2.c with the command:
  > 
  > ./xgcc -B./ -B/tools/contrib/HP-UX/B.10.20/hppa2.0/packages/egcs/hppa2.0-hp
  > -hpux10.20/bin/ -O2   -DIN_GCC -DHAIFA    -g -W -Wall -I./include  -fPIC -g
  > 1 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -fexceptions 
  > -I. -I. -I./config -I./../include -c \
  >       -DL${name} ./libgcc2.c -o _eh.o
  > 
  > In file included from gthr-default.h:1,
  >                  from gthr.h:98,
  >                  from ./libgcc2.c:3025:
  > gthr-dce.h: In function `__gthread_key_dtor':
  > gthr-dce.h:95: warning: unused parameter `key'
  > gthr-dce.h:95: warning: unused parameter `ptr'
  > gthr-dce.h: In function `__gthread_key_delete':
  > gthr-dce.h:104: warning: implicit declaration of function `pthread_key_dele
  > te'
  > 
  > Indeed, gthr-default.h includes gthr-dce.h, which #defines __GTHREADS
  > and includes pthread.h...
  > 
  > Isn't it so that one would want to define -DHAVE_GTHR_DEFAULT _only_
  > when building gcc/threads/libgcc.a (_not_ when building gcc/libgcc.a)?
Unsure.  The C++ people would have to chime in.  I don't do C++, threads or
exceptions :-)


  > Also, when debugging a file compiled with egcs on HP-UX 10.20, gdb
  > complains of the following:
  > 
  > warning: Unable to find __d_pid symbol in object file.
  > warning: Suggest linking with /opt/langtools/lib/end.o.
  > warning: GDB will be unable to track shl_load/shl_unload calls
What version of gdb?  Whatever it is it pre-dates support for debugging
dynamic objects on hpux10 and is very old (since I fixed this problem at
least 2 years ago).

Linking in end.o on hpux10 is highly undesirable.  If you attempt to do
so you'll find that your program will not link.

jeff

Re: egcs 1.1.2 vs. HP/UX 10.20

[Marc Girod]

>>>>> "JL" == Jeffrey A Law <law@upchuck.cygnus.com> writes:

>> An other note: I also have DCE threads installed, and egcs makes use
>> of them, with the result that any linking with gcc needs to be passed
>> the -ldce option.

JL> It's an issue, we just don't have a good solution.   If you've got one
JL> I'd love to hear it.

The dce symbols come (at least) from the object file _eh.o, archived
into libgcc2.a (and from there to libgcc.a).

It is compiled from gcc/libgcc2.c with the command:

./xgcc -B./ -B/tools/contrib/HP-UX/B.10.20/hppa2.0/packages/egcs/hppa2.0-hp-hpux10.20/bin/ -O2   -DIN_GCC -DHAIFA    -g -W -Wall -I./include  -fPIC -g1 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -fexceptions -I. -I. -I./config -I./../include -c \
      -DL${name} ./libgcc2.c -o _eh.o

In file included from gthr-default.h:1,
                 from gthr.h:98,
                 from ./libgcc2.c:3025:
gthr-dce.h: In function `__gthread_key_dtor':
gthr-dce.h:95: warning: unused parameter `key'
gthr-dce.h:95: warning: unused parameter `ptr'
gthr-dce.h: In function `__gthread_key_delete':
gthr-dce.h:104: warning: implicit declaration of function `pthread_key_delete'

Indeed, gthr-default.h includes gthr-dce.h, which #defines __GTHREADS
and includes pthread.h...

Isn't it so that one would want to define -DHAVE_GTHR_DEFAULT _only_
when building gcc/threads/libgcc.a (_not_ when building gcc/libgcc.a)?

Note: this is true as well with egcs-2.93.21 (ss-19990502).



Also, when debugging a file compiled with egcs on HP-UX 10.20, gdb
complains of the following:

warning: Unable to find __d_pid symbol in object file.
warning: Suggest linking with /opt/langtools/lib/end.o.
warning: GDB will be unable to track shl_load/shl_unload calls

This means that the c++ driver fails to, parsing the -g flag, add the
/opt/langtools/lib/end.o file as the last file named on the link line.

Indeed:

% nm++ /opt/langtools/lib/end.o | grep __d_pid
__d_pid             |1073745992|extern|data   |$SHORTDATA$


Best Regards!
Marc

-- 
Marc Girod                Hiomo 5/1          Voice:  +358-9-511 23746
Nokia Telecommunications  P.O. Box 320       Mobile: +358-40-569 7954
NWS/NMS/NMS for Data      00045 NOKIA Group  Fax:    +358-9-511 23580
                          Finland            marc.girod@ntc.nokia.com

Re: egcs 1.1.2 vs. HP/UX 10.20

[Marc Girod]

>>>>> "JL" == Jeffrey A Law <law@upchuck.cygnus.com> writes:

JL> Yes. They are referenced by the MT thread safe exception handling
JL> code.

Er... There are 2 versions of libgcc.a in the build directory: one in
the gcc directory, the other in the gcc/threads one.

Now, both versions reference the symbols. Is this intended?

If it is intended, then libdce is needed. The question can only be:
"archive or shared library?".

If one is making an archive libgcc.a, one can extract the symbols from
libdce.a into it in the same way as for the other symbols:

- make a tmp directory
- extract the symbols from libdce.a
- append the to libgcc.a
- clean up

The resulting lib will be bigger.

Using the shared lib would be cleaner, but it implies adding an
implicit -ldce to every user's link line.

JL> Correct.  They must be provided by the system thread libraries.

This is not what I meant. Indeed they are _provided_ by the thread
library, i.e. in this case, by libdce.

I was looking for the files _using_ them.

Best Regards!
Marc

-- 
Marc Girod                Hiomo 5/1          Voice:  +358-9-511 23746
Nokia Telecommunications  P.O. Box 320       Mobile: +358-40-569 7954
NWS/NMS/NMS for Data      00045 NOKIA Group  Fax:    +358-9-511 23580
                          Finland            marc.girod@ntc.nokia.com

Re: egcs 1.1.2 vs. HP/UX 10.20

[Marc Girod]

>>>>> "JL" == Jeffrey A Law <law@upchuck.cygnus.com> writes:

JL> Yes. They are referenced by the MT thread safe exception handling
JL> code.

Er... There are 2 versions of libgcc.a in the build directory: one in
the gcc directory, the other in the gcc/threads one.

Now, both versions reference the symbols. Is this intended?

If it is intended, then libdce is needed. The question can only be:
"archive or shared library?".

If one is making an archive libgcc.a, one can extract the symbols from
libdce.a into it in the same way as for the other symbols:

- make a tmp directory
- extract the symbols from libdce.a
- append the to libgcc.a
- clean up

The resulting lib will be bigger.

Using the shared lib would be cleaner, but it implies adding an
implicit -ldce to every user's link line.

JL> Correct.  They must be provided by the system thread libraries.

This is not what I meant. Indeed they are _provided_ by the thread
library, i.e. in this case, by libdce.

I was looking for the files _using_ them.

Best Regards!
Marc

-- 
Marc Girod                Hiomo 5/1          Voice:  +358-9-511 23746
Nokia Telecommunications  P.O. Box 320       Mobile: +358-40-569 7954
NWS/NMS/NMS for Data      00045 NOKIA Group  Fax:    +358-9-511 23580
                          Finland            marc.girod@ntc.nokia.com

Re: egcs 1.1.2 vs. HP/UX 10.20

[Jeffrey A Law]

  In message <1yvheq5uwc.fsf@mahtan.ntc.nokia.com>you write:
  > >>>>> "JL" == Jeffrey A Law <law@upchuck.cygnus.com> writes:
  > 
  > JL> Yes. They are referenced by the MT thread safe exception handling
  > JL> code.
  > 
  > Er... There are 2 versions of libgcc.a in the build directory: one in
  > the gcc directory, the other in the gcc/threads one.
  > 
  > Now, both versions reference the symbols. Is this intended?
I do not know.  You would have to ask the C++ and Java folks since they are
the ones that have libraries that need to be aware of the system's underlying
thread model.

  > If it is intended, then libdce is needed. The question can only be:
  > "archive or shared library?".
  > 
  > If one is making an archive libgcc.a, one can extract the symbols from
  > libdce.a into it in the same way as for the other symbols:
  > 
  > - make a tmp directory
  > - extract the symbols from libdce.a
  > - append the to libgcc.a
  > - clean up
  > 
  > The resulting lib will be bigger.
Worse, how do you describe these steps in a general manner?  How do you deal
with cross compilers?  Sucking in parts of a system library into libgcc is
a bad thing to be doing.

jeff

Re: egcs 1.1.2 vs. HP/UX 10.20

[Jeffrey A Law]

  In message <1yvheq5uwc.fsf@mahtan.ntc.nokia.com>you write:
  > >>>>> "JL" == Jeffrey A Law <law@upchuck.cygnus.com> writes:
  > 
  > JL> Yes. They are referenced by the MT thread safe exception handling
  > JL> code.
  > 
  > Er... There are 2 versions of libgcc.a in the build directory: one in
  > the gcc directory, the other in the gcc/threads one.
  > 
  > Now, both versions reference the symbols. Is this intended?
I do not know.  You would have to ask the C++ and Java folks since they are
the ones that have libraries that need to be aware of the system's underlying
thread model.

  > If it is intended, then libdce is needed. The question can only be:
  > "archive or shared library?".
  > 
  > If one is making an archive libgcc.a, one can extract the symbols from
  > libdce.a into it in the same way as for the other symbols:
  > 
  > - make a tmp directory
  > - extract the symbols from libdce.a
  > - append the to libgcc.a
  > - clean up
  > 
  > The resulting lib will be bigger.
Worse, how do you describe these steps in a general manner?  How do you deal
with cross compilers?  Sucking in parts of a system library into libgcc is
a bad thing to be doing.

jeff

Re: egcs 1.1.2 vs. HP/UX 10.20

[Marc Girod]

>>>>> "JL" == Jeffrey A Law <law@upchuck.cygnus.com> writes:

JL> What version of gdb?  Whatever it is it pre-dates support for debugging
JL> dynamic objects on hpux10 and is very old (since I fixed this problem at
JL> least 2 years ago).

Old? It depends... It was 4.18, built last week. OK, I didn't yet
get the latest patch from CVS!

JL> Linking in end.o on hpux10 is highly undesirable.  If you attempt to do
JL> so you'll find that your program will not link.

At least it works if done by hand:

% c++ -o foo -g -ldce foo.C /opt/langtools/lib/end.o

In the end of the debug session, I get (with and without end.o):

Program exited normally.
Error accessing memory address 0x7a9909b8: No such process.

Best Regards!
Marc

-- 
Marc Girod                Hiomo 5/1          Voice:  +358-9-511 23746
Nokia Telecommunications  P.O. Box 320       Mobile: +358-40-569 7954
NWS/NMS/NMS for Data      00045 NOKIA Group  Fax:    +358-9-511 23580
                          Finland            marc.girod@ntc.nokia.com

Re: egcs 1.1.2 vs. HP/UX 10.20

[Jeffrey A Law]

  In message < 1ybtg0hx8c.fsf@anvil.ntc.nokia.com >you write:
  > Old? It depends... It was 4.18, built last week. OK, I didn't yet
  > get the latest patch from CVS!
Hmmm, something's not right....

  > JL> Linking in end.o on hpux10 is highly undesirable.  If you attempt to do
  > JL> so you'll find that your program will not link.
  > 
  > At least it works if done by hand:
  > 
  > % c++ -o foo -g -ldce foo.C /opt/langtools/lib/end.o
Looks like HP might have (finally) fixed this problem.  Regardless gdb should
be able to debug dynamic code just fine without end.o on hpux10 systems.

This whole situation started because end.o is not always available and after
much poking HP agreed that it was wrong for the debuggability of a binary to
depend on a .o file from the unbundled compiler.  So they moved the necessary
functionality into crt0.o

Actually, it's d_pid that you're getting the warning for, right?   Tickle a
few brain cells by reviewing the source..  Ah...  Yes...  On hpux10 you will
get a warning about d_pid, but it's just a warning and the inability to find
d_pid will not effect gdb's ability to debug dynamic code on hpux10.


jeff

Re: egcs 1.1.2 vs. HP/UX 10.20

[Jeffrey A Law]

  In message < 1ybtg0hx8c.fsf@anvil.ntc.nokia.com >you write:
  > Old? It depends... It was 4.18, built last week. OK, I didn't yet
  > get the latest patch from CVS!
Hmmm, something's not right....

  > JL> Linking in end.o on hpux10 is highly undesirable.  If you attempt to do
  > JL> so you'll find that your program will not link.
  > 
  > At least it works if done by hand:
  > 
  > % c++ -o foo -g -ldce foo.C /opt/langtools/lib/end.o
Looks like HP might have (finally) fixed this problem.  Regardless gdb should
be able to debug dynamic code just fine without end.o on hpux10 systems.

This whole situation started because end.o is not always available and after
much poking HP agreed that it was wrong for the debuggability of a binary to
depend on a .o file from the unbundled compiler.  So they moved the necessary
functionality into crt0.o

Actually, it's d_pid that you're getting the warning for, right?   Tickle a
few brain cells by reviewing the source..  Ah...  Yes...  On hpux10 you will
get a warning about d_pid, but it's just a warning and the inability to find
d_pid will not effect gdb's ability to debug dynamic code on hpux10.


jeff

Re: egcs 1.1.2 vs. HP/UX 10.20

[Marc Girod]

>>>>> "JL" == Jeffrey A Law <law@upchuck.cygnus.com> writes:

JL> What version of gdb?  Whatever it is it pre-dates support for debugging
JL> dynamic objects on hpux10 and is very old (since I fixed this problem at
JL> least 2 years ago).

Old? It depends... It was 4.18, built last week. OK, I didn't yet
get the latest patch from CVS!

JL> Linking in end.o on hpux10 is highly undesirable.  If you attempt to do
JL> so you'll find that your program will not link.

At least it works if done by hand:

% c++ -o foo -g -ldce foo.C /opt/langtools/lib/end.o

In the end of the debug session, I get (with and without end.o):

Program exited normally.
Error accessing memory address 0x7a9909b8: No such process.

Best Regards!
Marc

-- 
Marc Girod                Hiomo 5/1          Voice:  +358-9-511 23746
Nokia Telecommunications  P.O. Box 320       Mobile: +358-40-569 7954
NWS/NMS/NMS for Data      00045 NOKIA Group  Fax:    +358-9-511 23580
                          Finland            marc.girod@ntc.nokia.com