You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Pier P. Fumagalli" <pi...@betaversion.org> on 2001/07/16 19:34:48 UTC
FW: latest cvs checkout test
I just tried it on Nagoya, and it does the same for me...
Do someone has _ANY_ clue of WTF is going on????
Pier
------ Forwarded Message
From: "Brian P. Millett" <bp...@ec-group.com>
Date: Mon, 16 Jul 2001 12:34:48 -0500
To: Pier Fumagalli <pi...@betaversion.org>
Subject: latest cvs checkout test
Hi Pier,
Here are my results from the latest cvs checkout and build:
(Solaris 8, x86; gcc version 2.95.2; java version "1.4.0-beta"; apache
1.3.20)
Steps:
1)rm -rf jakarta-servletapi-4 jakarta-tomcat-4.0
jakarta-tomcat-connectors
2) cvs co jakarta-servletapi-4 jakarta-tomcat-4.0
jakarta-tomcat-connectors
3) cd jakarta-tomcat-connectors/webapp; cvs co apr
4) cd jakarta-servletapi-4; ./build.sh dist (and install)
5) cd jakarta-tomcat-4.0; ./build.sh dist (and install)
6) cd jakarta-tomcat-connectors/webapp
7) sh support/buildconf.sh
8) ./configure --with-apxs=/opt/apache/bin/apxs
9) cp apache-1.3/mod_webapp.so /opt/apache/libexec/
10) /etc/init.d/tomcatctl start
11) /etc/init.d/apachectll start
Cannot load /opt/apache/libexec/mod_webapp.so into server:
ld.so.1: /opt/apache/bin/httpd: fatal: relocation error: file
/opt/apache/libexec/mod_webapp.so: symbol __divdi3: referenced symbol
not found
/opt/apache/bin/apachectl start: httpd could not be started
Otherwise, it looks OK. The __divdi3 symbol is found in libgcc.a
/opt/sfw/lib/gcc-lib/i386-pc-solaris2.8/2.95.2/libgcc.a[_divdi3.o]:
[Index] Value Size Type Bind Other Shndx Name
[2] | 0| 0|SECT |LOCL |0 |2 |
[3] | 0| 0|SECT |LOCL |0 |3 |
[4] | 0| 0|SECT |LOCL |0 |4 |
[5] | 0| 0|SECT |LOCL |0 |5 |
[7] | 0| 0|SECT |LOCL |0 |6 |
[6] | 0| 256|OBJT |LOCL |0 |5 |__clz_tab
[8] | 0| 414|FUNC |GLOB |0 |2 |__divdi3
[1] | 0| 0|FILE |LOCL |0 |ABS |libgcc2.c
Is that being referenced in apr? If so, why? Or is my gcc installation
broke?
Take care.
--
Brian Millett
Enterprise Consulting Group "Shifts in paradigms
(314) 205-9030 often cause nose bleeds."
bpm@ec-group.com Greg Glenn
------ End of Forwarded Message
Re: latest cvs checkout test
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Thanks a lot for the input, Brian... Just remember to CC dev@apr.apache.org,
if, as you show here, the stuff happens in APR... :)
Thanks a bazillion...
Pier
Brian P Millett at bpm@ec-group.com wrote:
> "Pier P. Fumagalli" wrote:
>> Brian P Millett at bpm@ec-group.com wrote:
>>> Justin Erenkrantz wrote:
>>>
>>>> On Mon, Jul 16, 2001 at 06:34:48PM +0100, Pier P. Fumagalli wrote:
>>>>> I just tried it on Nagoya, and it does the same for me...
>>>>> Do someone has _ANY_ clue of WTF is going on????
>>>>
>>>> Yeah, I've seen this before (Solaris, too). I had to add -lgcc.
>>>> Don't ask me why the linker didn't pick up on that automagically.
>>>> I never took the time to figure out why I had to do it. I'd
>>>> be curious to find out why though.
>>>
>>> was that just for the apr? Or for the mod_webapp?
>>
>> Same thing, when a library is linked, is linked... The real issue is _where_
>> that symbol is used...
>
> Well, this is what I did to find out that it is referenced in libapr.a.
>
> Went to apr/.libs and executed: "ar -xv libapr.a"
>
> Got a bunch of .o files, and checked them to see what as up. Looks like:
>
> shaka: for f in *.o ; do nm $f | grep divdi3; if [ $? -eq 0 ]; then echo $f;
> fi ; done
> [30] | 0| 0|NOTY |GLOB |0 |UNDEF |__udivdi3
> apr_snprintf.o
> [33] | 0| 0|NOTY |GLOB |0 |UNDEF |__divdi3
> poll.o
> [29] | 0| 0|NOTY |GLOB |0 |UNDEF |__divdi3
> readwrite.o
> [18] | 0| 0|NOTY |GLOB |0 |UNDEF |__divdi3
> sendrecv.o
> [29] | 0| 0|NOTY |GLOB |0 |UNDEF |__divdi3
> time.o
>
> So a nm on sendrecv.o shows:
> sendrecv.o:
>
> [Index] Value Size Type Bind Other Shndx Name
>
> [12] | 0| 0|SECT |LOCL |0 |6 |
> [2] | 0| 0|SECT |LOCL |0 |1 |
> [3] | 0| 0|SECT |LOCL |0 |3 |
> [4] | 0| 0|SECT |LOCL |0 |4 |
> [11] | 0| 0|SECT |LOCL |0 |5 |
> [21] | 0| 0|NOTY |GLOB |0 |UNDEF |___errno
> [18] | 0| 0|NOTY |GLOB |0 |UNDEF |__divdi3
> [19] | 0| 0|NOTY |GLOB |0 |UNDEF |__moddi3
> [13] | 0| 0|NOTY |GLOB |0 |UNDEF |__posix_asctime_r
> [14] | 0| 0|NOTY |GLOB |0 |UNDEF |__posix_ctime_r
> [16] | 0| 0|NOTY |GLOB |0 |UNDEF |__posix_getlogin_r
> [15] | 0| 0|NOTY |GLOB |0 |UNDEF |__posix_sigwait
> [17] | 0| 0|NOTY |GLOB |0 |UNDEF |__posix_ttyname_r
> [25] | 592| 199|FUNC |GLOB |0 |1 |apr_recv
> [29] | 1024| 260|FUNC |GLOB |0 |1 |apr_recvfrom
> [23] | 404| 187|FUNC |GLOB |0 |1 |apr_send
> [33] | 1476| 12|FUNC |GLOB |0 |1 |apr_sendfile
> [27] | 792| 230|FUNC |GLOB |0 |1 |apr_sendto
> [31] | 1284| 190|FUNC |GLOB |0 |1 |apr_sendv
> [20] | 144| 260|FUNC |GLOB |0 |1
> |apr_wait_for_io_or_timeout
> [6] | 0| 26|FUNC |LOCL |0 |1 |asctime_r
> [7] | 28| 26|FUNC |LOCL |0 |1 |ctime_r
> [5] | 0| 0|NOTY |LOCL |0 |1 |gcc2_compiled.
> [9] | 84| 26|FUNC |LOCL |0 |1 |getlogin_r
> [26] | 0| 0|NOTY |GLOB |0 |UNDEF |read
> [30] | 0| 0|NOTY |GLOB |0 |UNDEF |recvfrom
> [22] | 0| 0|NOTY |GLOB |0 |UNDEF |select
> [1] | 0| 0|FILE |LOCL |0 |ABS |sendrecv.c
> [28] | 0| 0|NOTY |GLOB |0 |UNDEF |sendto
> [8] | 56| 26|FUNC |LOCL |0 |1 |sigwait
> [10] | 112| 30|FUNC |LOCL |0 |1 |ttyname_r
> [24] | 0| 0|NOTY |GLOB |0 |UNDEF |write
> [32] | 0| 0|NOTY |GLOB |0 |UNDEF |writev
>
>
> Hope this helps someone. I've just about gone over my head here.
>
> --
> Brian Millett
> Enterprise Consulting Group "Shifts in paradigms
> (314) 205-9030 often cause nose bleeds."
> bpm@ec-group.com Greg Glenn
>
>
FW: latest cvs checkout test
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
FYI...
------ Forwarded Message
From: Brian P Millett <bp...@ec-group.com>
Organization: Enterprise Consulting Group
Date: Tue, 17 Jul 2001 17:16:32 -0500
To: tomcat-dev@jakarta.apache.org
Cc: Pier Fumagalli <pi...@betaversion.org>
Subject: Re: latest cvs checkout test
"Pier P. Fumagalli" wrote:
> Brian P Millett at bpm@ec-group.com wrote:
>
> > Justin Erenkrantz wrote:
> >
> >> On Mon, Jul 16, 2001 at 06:34:48PM +0100, Pier P. Fumagalli wrote:
> >>> I just tried it on Nagoya, and it does the same for me...
> >>> Do someone has _ANY_ clue of WTF is going on????
> >>
> >> Yeah, I've seen this before (Solaris, too). I had to add -lgcc.
> >> Don't ask me why the linker didn't pick up on that automagically.
> >> I never took the time to figure out why I had to do it. I'd
> >> be curious to find out why though.
> >
> > was that just for the apr? Or for the mod_webapp?
>
> Same thing, when a library is linked, is linked... The real issue is _where_
> that symbol is used...
Well, this is what I did to find out that it is referenced in libapr.a.
Went to apr/.libs and executed: "ar -xv libapr.a"
Got a bunch of .o files, and checked them to see what as up. Looks like:
shaka: for f in *.o ; do nm $f | grep divdi3; if [ $? -eq 0 ]; then echo $f;
fi ; done
[30] | 0| 0|NOTY |GLOB |0 |UNDEF |__udivdi3
apr_snprintf.o
[33] | 0| 0|NOTY |GLOB |0 |UNDEF |__divdi3
poll.o
[29] | 0| 0|NOTY |GLOB |0 |UNDEF |__divdi3
readwrite.o
[18] | 0| 0|NOTY |GLOB |0 |UNDEF |__divdi3
sendrecv.o
[29] | 0| 0|NOTY |GLOB |0 |UNDEF |__divdi3
time.o
So a nm on sendrecv.o shows:
sendrecv.o:
[Index] Value Size Type Bind Other Shndx Name
[12] | 0| 0|SECT |LOCL |0 |6 |
[2] | 0| 0|SECT |LOCL |0 |1 |
[3] | 0| 0|SECT |LOCL |0 |3 |
[4] | 0| 0|SECT |LOCL |0 |4 |
[11] | 0| 0|SECT |LOCL |0 |5 |
[21] | 0| 0|NOTY |GLOB |0 |UNDEF |___errno
[18] | 0| 0|NOTY |GLOB |0 |UNDEF |__divdi3
[19] | 0| 0|NOTY |GLOB |0 |UNDEF |__moddi3
[13] | 0| 0|NOTY |GLOB |0 |UNDEF |__posix_asctime_r
[14] | 0| 0|NOTY |GLOB |0 |UNDEF |__posix_ctime_r
[16] | 0| 0|NOTY |GLOB |0 |UNDEF |__posix_getlogin_r
[15] | 0| 0|NOTY |GLOB |0 |UNDEF |__posix_sigwait
[17] | 0| 0|NOTY |GLOB |0 |UNDEF |__posix_ttyname_r
[25] | 592| 199|FUNC |GLOB |0 |1 |apr_recv
[29] | 1024| 260|FUNC |GLOB |0 |1 |apr_recvfrom
[23] | 404| 187|FUNC |GLOB |0 |1 |apr_send
[33] | 1476| 12|FUNC |GLOB |0 |1 |apr_sendfile
[27] | 792| 230|FUNC |GLOB |0 |1 |apr_sendto
[31] | 1284| 190|FUNC |GLOB |0 |1 |apr_sendv
[20] | 144| 260|FUNC |GLOB |0 |1
|apr_wait_for_io_or_timeout
[6] | 0| 26|FUNC |LOCL |0 |1 |asctime_r
[7] | 28| 26|FUNC |LOCL |0 |1 |ctime_r
[5] | 0| 0|NOTY |LOCL |0 |1 |gcc2_compiled.
[9] | 84| 26|FUNC |LOCL |0 |1 |getlogin_r
[26] | 0| 0|NOTY |GLOB |0 |UNDEF |read
[30] | 0| 0|NOTY |GLOB |0 |UNDEF |recvfrom
[22] | 0| 0|NOTY |GLOB |0 |UNDEF |select
[1] | 0| 0|FILE |LOCL |0 |ABS |sendrecv.c
[28] | 0| 0|NOTY |GLOB |0 |UNDEF |sendto
[8] | 56| 26|FUNC |LOCL |0 |1 |sigwait
[10] | 112| 30|FUNC |LOCL |0 |1 |ttyname_r
[24] | 0| 0|NOTY |GLOB |0 |UNDEF |write
[32] | 0| 0|NOTY |GLOB |0 |UNDEF |writev
Hope this helps someone. I've just about gone over my head here.
--
Brian Millett
Enterprise Consulting Group "Shifts in paradigms
(314) 205-9030 often cause nose bleeds."
bpm@ec-group.com Greg Glenn
------ End of Forwarded Message
Re: latest cvs checkout test
Posted by Brian P Millett <bp...@ec-group.com>.
"Pier P. Fumagalli" wrote:
> Brian P Millett at bpm@ec-group.com wrote:
>
> > Justin Erenkrantz wrote:
> >
> >> On Mon, Jul 16, 2001 at 06:34:48PM +0100, Pier P. Fumagalli wrote:
> >>> I just tried it on Nagoya, and it does the same for me...
> >>> Do someone has _ANY_ clue of WTF is going on????
> >>
> >> Yeah, I've seen this before (Solaris, too). I had to add -lgcc.
> >> Don't ask me why the linker didn't pick up on that automagically.
> >> I never took the time to figure out why I had to do it. I'd
> >> be curious to find out why though.
> >
> > was that just for the apr? Or for the mod_webapp?
>
> Same thing, when a library is linked, is linked... The real issue is _where_
> that symbol is used...
Well, this is what I did to find out that it is referenced in libapr.a.
Went to apr/.libs and executed: "ar -xv libapr.a"
Got a bunch of .o files, and checked them to see what as up. Looks like:
shaka: for f in *.o ; do nm $f | grep divdi3; if [ $? -eq 0 ]; then echo $f; fi ; done
[30] | 0| 0|NOTY |GLOB |0 |UNDEF |__udivdi3
apr_snprintf.o
[33] | 0| 0|NOTY |GLOB |0 |UNDEF |__divdi3
poll.o
[29] | 0| 0|NOTY |GLOB |0 |UNDEF |__divdi3
readwrite.o
[18] | 0| 0|NOTY |GLOB |0 |UNDEF |__divdi3
sendrecv.o
[29] | 0| 0|NOTY |GLOB |0 |UNDEF |__divdi3
time.o
So a nm on sendrecv.o shows:
sendrecv.o:
[Index] Value Size Type Bind Other Shndx Name
[12] | 0| 0|SECT |LOCL |0 |6 |
[2] | 0| 0|SECT |LOCL |0 |1 |
[3] | 0| 0|SECT |LOCL |0 |3 |
[4] | 0| 0|SECT |LOCL |0 |4 |
[11] | 0| 0|SECT |LOCL |0 |5 |
[21] | 0| 0|NOTY |GLOB |0 |UNDEF |___errno
[18] | 0| 0|NOTY |GLOB |0 |UNDEF |__divdi3
[19] | 0| 0|NOTY |GLOB |0 |UNDEF |__moddi3
[13] | 0| 0|NOTY |GLOB |0 |UNDEF |__posix_asctime_r
[14] | 0| 0|NOTY |GLOB |0 |UNDEF |__posix_ctime_r
[16] | 0| 0|NOTY |GLOB |0 |UNDEF |__posix_getlogin_r
[15] | 0| 0|NOTY |GLOB |0 |UNDEF |__posix_sigwait
[17] | 0| 0|NOTY |GLOB |0 |UNDEF |__posix_ttyname_r
[25] | 592| 199|FUNC |GLOB |0 |1 |apr_recv
[29] | 1024| 260|FUNC |GLOB |0 |1 |apr_recvfrom
[23] | 404| 187|FUNC |GLOB |0 |1 |apr_send
[33] | 1476| 12|FUNC |GLOB |0 |1 |apr_sendfile
[27] | 792| 230|FUNC |GLOB |0 |1 |apr_sendto
[31] | 1284| 190|FUNC |GLOB |0 |1 |apr_sendv
[20] | 144| 260|FUNC |GLOB |0 |1 |apr_wait_for_io_or_timeout
[6] | 0| 26|FUNC |LOCL |0 |1 |asctime_r
[7] | 28| 26|FUNC |LOCL |0 |1 |ctime_r
[5] | 0| 0|NOTY |LOCL |0 |1 |gcc2_compiled.
[9] | 84| 26|FUNC |LOCL |0 |1 |getlogin_r
[26] | 0| 0|NOTY |GLOB |0 |UNDEF |read
[30] | 0| 0|NOTY |GLOB |0 |UNDEF |recvfrom
[22] | 0| 0|NOTY |GLOB |0 |UNDEF |select
[1] | 0| 0|FILE |LOCL |0 |ABS |sendrecv.c
[28] | 0| 0|NOTY |GLOB |0 |UNDEF |sendto
[8] | 56| 26|FUNC |LOCL |0 |1 |sigwait
[10] | 112| 30|FUNC |LOCL |0 |1 |ttyname_r
[24] | 0| 0|NOTY |GLOB |0 |UNDEF |write
[32] | 0| 0|NOTY |GLOB |0 |UNDEF |writev
Hope this helps someone. I've just about gone over my head here.
--
Brian Millett
Enterprise Consulting Group "Shifts in paradigms
(314) 205-9030 often cause nose bleeds."
bpm@ec-group.com Greg Glenn
Re: latest cvs checkout test
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Brian P Millett at bpm@ec-group.com wrote:
> Justin Erenkrantz wrote:
>
>> On Mon, Jul 16, 2001 at 06:34:48PM +0100, Pier P. Fumagalli wrote:
>>> I just tried it on Nagoya, and it does the same for me...
>>> Do someone has _ANY_ clue of WTF is going on????
>>
>> Yeah, I've seen this before (Solaris, too). I had to add -lgcc.
>> Don't ask me why the linker didn't pick up on that automagically.
>> I never took the time to figure out why I had to do it. I'd
>> be curious to find out why though.
>
> was that just for the apr? Or for the mod_webapp?
Same thing, when a library is linked, is linked... The real issue is _where_
that symbol is used...
Pier
Re: FW: latest cvs checkout test
Posted by Brian P Millett <bp...@ec-group.com>.
Justin Erenkrantz wrote:
> On Mon, Jul 16, 2001 at 06:34:48PM +0100, Pier P. Fumagalli wrote:
> > I just tried it on Nagoya, and it does the same for me...
> > Do someone has _ANY_ clue of WTF is going on????
>
> Yeah, I've seen this before (Solaris, too). I had to add -lgcc.
> Don't ask me why the linker didn't pick up on that automagically.
> I never took the time to figure out why I had to do it. I'd
> be curious to find out why though.
was that just for the apr? Or for the mod_webapp?
--
Brian Millett
Enterprise Consulting Group "Shifts in paradigms
(314) 205-9030 often cause nose bleeds."
bpm@ec-group.com Greg Glenn
Re: FW: latest cvs checkout test
Posted by Dale Ghent <da...@elemental.org>.
On Mon, 16 Jul 2001, Justin Erenkrantz wrote:
| On Mon, Jul 16, 2001 at 06:34:48PM +0100, Pier P. Fumagalli wrote:
| > I just tried it on Nagoya, and it does the same for me...
| > Do someone has _ANY_ clue of WTF is going on????
|
| Yeah, I've seen this before (Solaris, too). I had to add -lgcc.
| Don't ask me why the linker didn't pick up on that automagically.
| I never took the time to figure out why I had to do it. I'd
| be curious to find out why though. -- justin
That's because libgcc is a static lib that, by default, lives in
/usr/local/lib/gcc-lib/*/*/
gcc should have linked it in automatically.
/dale
Re: FW: latest cvs checkout test
Posted by Dale Ghent <da...@elemental.org>.
On Mon, 16 Jul 2001, Justin Erenkrantz wrote:
| On Mon, Jul 16, 2001 at 06:34:48PM +0100, Pier P. Fumagalli wrote:
| > I just tried it on Nagoya, and it does the same for me...
| > Do someone has _ANY_ clue of WTF is going on????
|
| Yeah, I've seen this before (Solaris, too). I had to add -lgcc.
| Don't ask me why the linker didn't pick up on that automagically.
| I never took the time to figure out why I had to do it. I'd
| be curious to find out why though. -- justin
That's because libgcc is a static lib that, by default, lives in
/usr/local/lib/gcc-lib/*/*/
gcc should have linked it in automatically.
/dale
Re: FW: latest cvs checkout test
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Mon, Jul 16, 2001 at 06:34:48PM +0100, Pier P. Fumagalli wrote:
> I just tried it on Nagoya, and it does the same for me...
> Do someone has _ANY_ clue of WTF is going on????
Yeah, I've seen this before (Solaris, too). I had to add -lgcc.
Don't ask me why the linker didn't pick up on that automagically.
I never took the time to figure out why I had to do it. I'd
be curious to find out why though. -- justin
> ------ Forwarded Message
> From: "Brian P. Millett" <bp...@ec-group.com>
> Date: Mon, 16 Jul 2001 12:34:48 -0500
> To: Pier Fumagalli <pi...@betaversion.org>
> Subject: latest cvs checkout test
>
> Hi Pier,
> Here are my results from the latest cvs checkout and build:
>
> (Solaris 8, x86; gcc version 2.95.2; java version "1.4.0-beta"; apache
> 1.3.20)
>
> Steps:
> 1)rm -rf jakarta-servletapi-4 jakarta-tomcat-4.0
> jakarta-tomcat-connectors
> 2) cvs co jakarta-servletapi-4 jakarta-tomcat-4.0
> jakarta-tomcat-connectors
> 3) cd jakarta-tomcat-connectors/webapp; cvs co apr
> 4) cd jakarta-servletapi-4; ./build.sh dist (and install)
> 5) cd jakarta-tomcat-4.0; ./build.sh dist (and install)
> 6) cd jakarta-tomcat-connectors/webapp
> 7) sh support/buildconf.sh
> 8) ./configure --with-apxs=/opt/apache/bin/apxs
> 9) cp apache-1.3/mod_webapp.so /opt/apache/libexec/
> 10) /etc/init.d/tomcatctl start
> 11) /etc/init.d/apachectll start
>
> Cannot load /opt/apache/libexec/mod_webapp.so into server:
> ld.so.1: /opt/apache/bin/httpd: fatal: relocation error: file
> /opt/apache/libexec/mod_webapp.so: symbol __divdi3: referenced symbol
> not found
> /opt/apache/bin/apachectl start: httpd could not be started
>
> Otherwise, it looks OK. The __divdi3 symbol is found in libgcc.a
>
> /opt/sfw/lib/gcc-lib/i386-pc-solaris2.8/2.95.2/libgcc.a[_divdi3.o]:
>
> [Index] Value Size Type Bind Other Shndx Name
>
> [2] | 0| 0|SECT |LOCL |0 |2 |
> [3] | 0| 0|SECT |LOCL |0 |3 |
> [4] | 0| 0|SECT |LOCL |0 |4 |
> [5] | 0| 0|SECT |LOCL |0 |5 |
> [7] | 0| 0|SECT |LOCL |0 |6 |
> [6] | 0| 256|OBJT |LOCL |0 |5 |__clz_tab
> [8] | 0| 414|FUNC |GLOB |0 |2 |__divdi3
> [1] | 0| 0|FILE |LOCL |0 |ABS |libgcc2.c
>
>
> Is that being referenced in apr? If so, why? Or is my gcc installation
> broke?
>
> Take care.
>
> --
> Brian Millett
> Enterprise Consulting Group "Shifts in paradigms
> (314) 205-9030 often cause nose bleeds."
> bpm@ec-group.com Greg Glenn
>
>
> ------ End of Forwarded Message
Re: FW: latest cvs checkout test
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Mon, Jul 16, 2001 at 06:34:48PM +0100, Pier P. Fumagalli wrote:
> I just tried it on Nagoya, and it does the same for me...
> Do someone has _ANY_ clue of WTF is going on????
Yeah, I've seen this before (Solaris, too). I had to add -lgcc.
Don't ask me why the linker didn't pick up on that automagically.
I never took the time to figure out why I had to do it. I'd
be curious to find out why though. -- justin
> ------ Forwarded Message
> From: "Brian P. Millett" <bp...@ec-group.com>
> Date: Mon, 16 Jul 2001 12:34:48 -0500
> To: Pier Fumagalli <pi...@betaversion.org>
> Subject: latest cvs checkout test
>
> Hi Pier,
> Here are my results from the latest cvs checkout and build:
>
> (Solaris 8, x86; gcc version 2.95.2; java version "1.4.0-beta"; apache
> 1.3.20)
>
> Steps:
> 1)rm -rf jakarta-servletapi-4 jakarta-tomcat-4.0
> jakarta-tomcat-connectors
> 2) cvs co jakarta-servletapi-4 jakarta-tomcat-4.0
> jakarta-tomcat-connectors
> 3) cd jakarta-tomcat-connectors/webapp; cvs co apr
> 4) cd jakarta-servletapi-4; ./build.sh dist (and install)
> 5) cd jakarta-tomcat-4.0; ./build.sh dist (and install)
> 6) cd jakarta-tomcat-connectors/webapp
> 7) sh support/buildconf.sh
> 8) ./configure --with-apxs=/opt/apache/bin/apxs
> 9) cp apache-1.3/mod_webapp.so /opt/apache/libexec/
> 10) /etc/init.d/tomcatctl start
> 11) /etc/init.d/apachectll start
>
> Cannot load /opt/apache/libexec/mod_webapp.so into server:
> ld.so.1: /opt/apache/bin/httpd: fatal: relocation error: file
> /opt/apache/libexec/mod_webapp.so: symbol __divdi3: referenced symbol
> not found
> /opt/apache/bin/apachectl start: httpd could not be started
>
> Otherwise, it looks OK. The __divdi3 symbol is found in libgcc.a
>
> /opt/sfw/lib/gcc-lib/i386-pc-solaris2.8/2.95.2/libgcc.a[_divdi3.o]:
>
> [Index] Value Size Type Bind Other Shndx Name
>
> [2] | 0| 0|SECT |LOCL |0 |2 |
> [3] | 0| 0|SECT |LOCL |0 |3 |
> [4] | 0| 0|SECT |LOCL |0 |4 |
> [5] | 0| 0|SECT |LOCL |0 |5 |
> [7] | 0| 0|SECT |LOCL |0 |6 |
> [6] | 0| 256|OBJT |LOCL |0 |5 |__clz_tab
> [8] | 0| 414|FUNC |GLOB |0 |2 |__divdi3
> [1] | 0| 0|FILE |LOCL |0 |ABS |libgcc2.c
>
>
> Is that being referenced in apr? If so, why? Or is my gcc installation
> broke?
>
> Take care.
>
> --
> Brian Millett
> Enterprise Consulting Group "Shifts in paradigms
> (314) 205-9030 often cause nose bleeds."
> bpm@ec-group.com Greg Glenn
>
>
> ------ End of Forwarded Message