Thanks a lot for the input, Brian... Just remember to CC [EMAIL PROTECTED],
if, as you show here, the stuff happens in APR... :)
Thanks a bazillion...
Pier
Brian P Millett at [EMAIL PROTECTED] wrote:
> "Pier P. Fumagalli" wrote:
>> Brian P Millett at [EMAIL PROTECTED] 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."
> [EMAIL PROTECTED] Greg Glenn
>
>
