apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pier P. Fumagalli" <p...@betaversion.org>
Subject FW: latest cvs checkout test
Date Tue, 17 Jul 2001 22:18:08 GMT
FYI...


------ Forwarded Message
From: Brian P Millett <bpm@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 <pier@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


Mime
View raw message