* Re: egcs 1.1.2 vs. HP/UX 10.20 [not found] <nms.mail.egcs/Pine.LNX.4.04.9904082118420.494-100000@pm3o-30.pacificnet.net> @ 1999-04-08 22:39 ` Marc Girod 1999-04-10 1:17 ` Jeffrey A Law 1999-04-30 23:15 ` Marc Girod 0 siblings, 2 replies; 24+ messages in thread From: Marc Girod @ 1999-04-08 22:39 UTC (permalink / raw) To: egcs >>>>> "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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: egcs 1.1.2 vs. HP/UX 10.20 1999-04-08 22:39 ` egcs 1.1.2 vs. HP/UX 10.20 Marc Girod @ 1999-04-10 1:17 ` Jeffrey A Law 1999-04-30 23:15 ` Jeffrey A Law 1999-04-30 23:15 ` Marc Girod 1 sibling, 1 reply; 24+ messages in thread From: Jeffrey A Law @ 1999-04-10 1:17 UTC (permalink / raw) To: Marc Girod; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: egcs 1.1.2 vs. HP/UX 10.20 1999-04-10 1:17 ` Jeffrey A Law @ 1999-04-30 23:15 ` Jeffrey A Law 0 siblings, 0 replies; 24+ messages in thread From: Jeffrey A Law @ 1999-04-30 23:15 UTC (permalink / raw) To: Marc Girod; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: egcs 1.1.2 vs. HP/UX 10.20 1999-04-08 22:39 ` egcs 1.1.2 vs. HP/UX 10.20 Marc Girod 1999-04-10 1:17 ` Jeffrey A Law @ 1999-04-30 23:15 ` Marc Girod 1 sibling, 0 replies; 24+ messages in thread From: Marc Girod @ 1999-04-30 23:15 UTC (permalink / raw) To: egcs >>>>> "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 ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <nms.mail.egcs/1yaevlotru.fsf@anvil.ntc.nokia.com>]
[parent not found: <nms.mail.egcs/2756.925846479@upchuck.cygnus.com>]
* Re: egcs 1.1.2 vs. HP/UX 10.20 [not found] ` <nms.mail.egcs/2756.925846479@upchuck.cygnus.com> @ 1999-05-04 23:00 ` Marc Girod 1999-05-06 23:56 ` Jeffrey A Law 1999-05-31 21:36 ` Marc Girod 0 siblings, 2 replies; 24+ messages in thread From: Marc Girod @ 1999-05-04 23:00 UTC (permalink / raw) To: egcs >>>>> "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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: egcs 1.1.2 vs. HP/UX 10.20 1999-05-04 23:00 ` Marc Girod @ 1999-05-06 23:56 ` Jeffrey A Law 1999-05-31 21:36 ` Jeffrey A Law 1999-05-31 21:36 ` Marc Girod 1 sibling, 1 reply; 24+ messages in thread From: Jeffrey A Law @ 1999-05-06 23:56 UTC (permalink / raw) To: Marc Girod; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: egcs 1.1.2 vs. HP/UX 10.20 1999-05-06 23:56 ` Jeffrey A Law @ 1999-05-31 21:36 ` Jeffrey A Law 0 siblings, 0 replies; 24+ messages in thread From: Jeffrey A Law @ 1999-05-31 21:36 UTC (permalink / raw) To: Marc Girod; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: egcs 1.1.2 vs. HP/UX 10.20 1999-05-04 23:00 ` Marc Girod 1999-05-06 23:56 ` Jeffrey A Law @ 1999-05-31 21:36 ` Marc Girod 1 sibling, 0 replies; 24+ messages in thread From: Marc Girod @ 1999-05-31 21:36 UTC (permalink / raw) To: egcs >>>>> "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 ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <nms.mail.egcs/1y90bpsovo.fsf@mahtan.ntc.nokia.com>]
[parent not found: <nms.mail.egcs/488.924544529@upchuck.cygnus.com>]
* Re: egcs 1.1.2 vs. HP/UX 10.20 [not found] ` <nms.mail.egcs/488.924544529@upchuck.cygnus.com> @ 1999-04-20 23:51 ` Marc Girod 1999-04-30 23:15 ` Marc Girod 1999-05-23 23:36 ` Jeffrey A Law 0 siblings, 2 replies; 24+ messages in thread From: Marc Girod @ 1999-04-20 23:51 UTC (permalink / raw) To: egcs >>>>> "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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: egcs 1.1.2 vs. HP/UX 10.20 1999-04-20 23:51 ` Marc Girod @ 1999-04-30 23:15 ` Marc Girod 1999-05-23 23:36 ` Jeffrey A Law 1 sibling, 0 replies; 24+ messages in thread From: Marc Girod @ 1999-04-30 23:15 UTC (permalink / raw) To: egcs >>>>> "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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: egcs 1.1.2 vs. HP/UX 10.20 1999-04-20 23:51 ` Marc Girod 1999-04-30 23:15 ` Marc Girod @ 1999-05-23 23:36 ` Jeffrey A Law 1999-05-31 21:36 ` Jeffrey A Law 1 sibling, 1 reply; 24+ messages in thread From: Jeffrey A Law @ 1999-05-23 23:36 UTC (permalink / raw) To: Marc Girod; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: egcs 1.1.2 vs. HP/UX 10.20 1999-05-23 23:36 ` Jeffrey A Law @ 1999-05-31 21:36 ` Jeffrey A Law 0 siblings, 0 replies; 24+ messages in thread From: Jeffrey A Law @ 1999-05-31 21:36 UTC (permalink / raw) To: Marc Girod; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <nms.mail.egcs/1yemlunyiq.fsf@mahtan.ntc.nokia.com>]
[parent not found: <nms.mail.egcs/19990410081733$781c@stybba.ntc.nokia.com>]
* Re: egcs 1.1.2 vs. HP/UX 10.20 [not found] ` <nms.mail.egcs/19990410081733$781c@stybba.ntc.nokia.com> @ 1999-04-18 12:35 ` Marc Girod 1999-04-20 9:26 ` Jeffrey A Law 1999-04-30 23:15 ` Marc Girod 1999-05-04 6:22 ` Marc Girod 1 sibling, 2 replies; 24+ messages in thread From: Marc Girod @ 1999-04-18 12:35 UTC (permalink / raw) To: egcs >>>>> "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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: egcs 1.1.2 vs. HP/UX 10.20 1999-04-18 12:35 ` Marc Girod @ 1999-04-20 9:26 ` Jeffrey A Law 1999-04-30 23:15 ` Jeffrey A Law 1999-04-30 23:15 ` Marc Girod 1 sibling, 1 reply; 24+ messages in thread From: Jeffrey A Law @ 1999-04-20 9:26 UTC (permalink / raw) To: Marc Girod; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: egcs 1.1.2 vs. HP/UX 10.20 1999-04-20 9:26 ` Jeffrey A Law @ 1999-04-30 23:15 ` Jeffrey A Law 0 siblings, 0 replies; 24+ messages in thread From: Jeffrey A Law @ 1999-04-30 23:15 UTC (permalink / raw) To: Marc Girod; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: egcs 1.1.2 vs. HP/UX 10.20 1999-04-18 12:35 ` Marc Girod 1999-04-20 9:26 ` Jeffrey A Law @ 1999-04-30 23:15 ` Marc Girod 1 sibling, 0 replies; 24+ messages in thread From: Marc Girod @ 1999-04-30 23:15 UTC (permalink / raw) To: egcs >>>>> "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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: egcs 1.1.2 vs. HP/UX 10.20 [not found] ` <nms.mail.egcs/19990410081733$781c@stybba.ntc.nokia.com> 1999-04-18 12:35 ` Marc Girod @ 1999-05-04 6:22 ` Marc Girod 1999-05-04 12:37 ` Jeffrey A Law 1999-05-31 21:36 ` Marc Girod 1 sibling, 2 replies; 24+ messages in thread From: Marc Girod @ 1999-05-04 6:22 UTC (permalink / raw) To: egcs >>>>> "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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: egcs 1.1.2 vs. HP/UX 10.20 1999-05-04 6:22 ` Marc Girod @ 1999-05-04 12:37 ` Jeffrey A Law 1999-05-31 21:36 ` Jeffrey A Law 1999-05-31 21:36 ` Marc Girod 1 sibling, 1 reply; 24+ messages in thread From: Jeffrey A Law @ 1999-05-04 12:37 UTC (permalink / raw) To: Marc Girod; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: egcs 1.1.2 vs. HP/UX 10.20 1999-05-04 12:37 ` Jeffrey A Law @ 1999-05-31 21:36 ` Jeffrey A Law 0 siblings, 0 replies; 24+ messages in thread From: Jeffrey A Law @ 1999-05-31 21:36 UTC (permalink / raw) To: Marc Girod; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: egcs 1.1.2 vs. HP/UX 10.20 1999-05-04 6:22 ` Marc Girod 1999-05-04 12:37 ` Jeffrey A Law @ 1999-05-31 21:36 ` Marc Girod 1 sibling, 0 replies; 24+ messages in thread From: Marc Girod @ 1999-05-31 21:36 UTC (permalink / raw) To: egcs >>>>> "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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* egcs 1.1.2 vs. HP/UX 10.20 @ 1999-04-08 21:28 Stephen Walton 1999-04-10 1:15 ` Jeffrey A Law 1999-04-30 23:15 ` Stephen Walton 0 siblings, 2 replies; 24+ messages in thread From: Stephen Walton @ 1999-04-08 21:28 UTC (permalink / raw) To: egcs 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: egcs 1.1.2 vs. HP/UX 10.20 1999-04-08 21:28 Stephen Walton @ 1999-04-10 1:15 ` Jeffrey A Law 1999-04-30 23:15 ` Jeffrey A Law 1999-04-30 23:15 ` Stephen Walton 1 sibling, 1 reply; 24+ messages in thread From: Jeffrey A Law @ 1999-04-10 1:15 UTC (permalink / raw) To: swalton; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: egcs 1.1.2 vs. HP/UX 10.20 1999-04-10 1:15 ` Jeffrey A Law @ 1999-04-30 23:15 ` Jeffrey A Law 0 siblings, 0 replies; 24+ messages in thread From: Jeffrey A Law @ 1999-04-30 23:15 UTC (permalink / raw) To: swalton; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* egcs 1.1.2 vs. HP/UX 10.20 1999-04-08 21:28 Stephen Walton 1999-04-10 1:15 ` Jeffrey A Law @ 1999-04-30 23:15 ` Stephen Walton 1 sibling, 0 replies; 24+ messages in thread From: Stephen Walton @ 1999-04-30 23:15 UTC (permalink / raw) To: egcs 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~1999-05-31 21:36 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <nms.mail.egcs/Pine.LNX.4.04.9904082118420.494-100000@pm3o-30.pacificnet.net> 1999-04-08 22:39 ` egcs 1.1.2 vs. HP/UX 10.20 Marc Girod 1999-04-10 1:17 ` Jeffrey A Law 1999-04-30 23:15 ` Jeffrey A Law 1999-04-30 23:15 ` Marc Girod [not found] <nms.mail.egcs/1yaevlotru.fsf@anvil.ntc.nokia.com> [not found] ` <nms.mail.egcs/2756.925846479@upchuck.cygnus.com> 1999-05-04 23:00 ` Marc Girod 1999-05-06 23:56 ` Jeffrey A Law 1999-05-31 21:36 ` Jeffrey A Law 1999-05-31 21:36 ` Marc Girod [not found] <nms.mail.egcs/1y90bpsovo.fsf@mahtan.ntc.nokia.com> [not found] ` <nms.mail.egcs/488.924544529@upchuck.cygnus.com> 1999-04-20 23:51 ` Marc Girod 1999-04-30 23:15 ` Marc Girod 1999-05-23 23:36 ` Jeffrey A Law 1999-05-31 21:36 ` Jeffrey A Law [not found] <nms.mail.egcs/1yemlunyiq.fsf@mahtan.ntc.nokia.com> [not found] ` <nms.mail.egcs/19990410081733$781c@stybba.ntc.nokia.com> 1999-04-18 12:35 ` Marc Girod 1999-04-20 9:26 ` Jeffrey A Law 1999-04-30 23:15 ` Jeffrey A Law 1999-04-30 23:15 ` Marc Girod 1999-05-04 6:22 ` Marc Girod 1999-05-04 12:37 ` Jeffrey A Law 1999-05-31 21:36 ` Jeffrey A Law 1999-05-31 21:36 ` Marc Girod 1999-04-08 21:28 Stephen Walton 1999-04-10 1:15 ` Jeffrey A Law 1999-04-30 23:15 ` Jeffrey A Law 1999-04-30 23:15 ` Stephen Walton
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).