RE: [evlog-dev] -- plugin problem

Hi Hien,

The problem is solved after followed your steps. 

I have a quesstion here, does current evlog support IA64? I can't find dir
ia64 in evlog/kernel/v2.4.18/arch, though I found some "defined(__ia64__)"
in the implementation.

Another thing is I found the glibc-2.2.4-31.2 in redhat 2.1AS has a problem.
I don't know whether encountered this, but I had to replace the code in file
backendmgr.c line 46 with

- ext = (char *) strrchr(name, '.');
+ ext = name + 9; /* sample_be has 9 chars */

It is ugly, but I otherwise I got a segment fault. Because the returned ext
from strrchr() is '0x3213c', but it should be '0x600000000003213c'.

BTW, can you use the tcp_rmtlog_be in IA64? I can't, it seems to halt in
file tcp_rmtlog_be.c line 358 when opening the fifo.

Thanks,
-Zhu Yi

-----Original Message-----
From: Hien Nguyen [mailto:[email protected]]
Sent: 2003?1?17? 1:46
To: Hien Nguyen
Cc: Zhu, Yi; 'Steve Woodruff'; evlog mailing list
Subject: Re: [evlog-dev] -- plugin problem


Hi Steve, Yi,

I got it to work on my IA64 now. It is basically a linker problem. You 
need to modify the libevl Makefile under evlog/user/lib/Makefile to link 
  with the libgcc_s.so

Mine was looking like this

libevl.so: $(DOTSOS) query/made template/made util/made
         rm -f libevl.so
         ld -share -soname libevl.so.1 -o libevl.so $(LIB_SO) -lc 
-L/home/janis/gnu/tools/gcc-mainline/lib -lgcc_s

I am not sure why we have to dothis on the IA64 and not IA32, could it 
be a linker bug or gcc bug?

Thanks, Hien.

Hien Nguyen wrote:
> Yes, I got the same problem as Yi and Steve on my IA64 as I tried it 
> last night.
> 
> ./evlogd: relocation error: /usr/lib/libevl.so.1: undefined symbol: 
> __moddi3
> 
> I am gooing to look for solution (work around) for this problem.
> 
> Hien.
> 
> Zhu, Yi wrote:
> 
>> Hi,
>>
>> I got the same problem with Steve. My 4-way IA64 with Redhat 2.1AS 
>> also got
>> the relocation error when using the plugin share libraries. Instead, my
>> error is "relocation error: /usr/lib/libevl.so.1: undefined symbol:
>> __moddi3".
>> Below is the gdb trace
>>
>> 200             for(i = 0; i < MAX_BACKENDS; i++) {
>> (gdb) n
>> 201                     if (be_table[i].func != NULL) {
>> (gdb) print be_table
>> $1 = {{plugin = 0x600000000001f210, func = 0x200000000003f7b8 
>> <local+8424>,
>> state = 0}, {plugin = 0x0,     func = 0, state = 0}, {plugin = 0x0, 
>> func = 0, state = 0}, {plugin =
>> 0x0, func = 0, state = 0}, {
>>     plugin = 0x0, func = 0, state = 0}, {plugin = 0x0, func = 0, state 
>> = 0},
>> {plugin = 0x0, func = 0,     state = 0}, {plugin = 0x0, func = 0, 
>> state = 0}, {plugin = 0x0, func =
>> 0, state = 0}, {plugin = 0x0,     func = 0, state = 0}}
>> (gdb) n
>> 202                             func_ret = (*(be_table[i].func))(data1,
>> data2, evl_callback);
>> (gdb) n
>> ------------Got events.-----------------
>> Read 95 bytes from pipe
>> ./evlogd: relocation error: /usr/lib/libevl.so.1: undefined symbol: 
>> __moddi3
>> 203                             if (func_ret != 0) {
>> (gdb)
>>
>> But I don't think it is the evlog bug. It must be some bug related to the
>> ia64 glibc relocation, because the __moddi3 is defined in glibc and 
>> uses by
>> libevl.so.1. My glibc version is 2.2.4-29.2.
>>
>> Thanks,
>> -Zhu Yi
>>
>> -----Original Message-----
>> From: Zhu, Yi [mailto:[email protected]]
>> Sent: 2003?1?16? 11:39
>> To: 'Steve Woodruff'; evlog mailing list
>> Subject: RE: [evlog-dev] -- plugin problem
>>
>>
>> Hi Steve,
>>
>> The defined LOG_POSIX_PRINTF v2.4.18 include/linux/evl_log.h is only 
>> in the
>> CVS, it is not in 1.5.0 source rpm. See the list before, I submitted a 
>> patch
>> to fix the bug.
>>
>> I have an IA64 machine with me, I'll try to setup it after lunch. :)
>>
>> Thanks,
>> -Zhu Yi
>>
>>
>>> -----Original Message-----
>>> From: Steve Woodruff [mailto:[email protected]]
>>> Sent: Thursday, January 16, 2003 11:32 AM
>>> To: evlog mailing list
>>> Subject: RE: [evlog-dev] -- plugin problem
>>>
>>>
>>> Hi,
>>>
>>> Yes - this is a HP RX2600 (IA64).  The __umodsi3
>>> symbol is in libgcc_s.so -- and it shows up in
>>> /proc/ksysms.
>>>
>>> I didn't grab source from cvs, but rather the
>>> 1.5.0 source rpm from the project site.  You
>>> say that the v2.4.18 include/linux/evl_log.h
>>> has LOG_POSIX_PRINTF defined?  Hein, did u
>>> just add that today?
>>>
>>> Thanks!
>>>
>>> /steve
>>>
>>>
>>>
>>> --- "Zhu, Yi" <[email protected]> wrote:
>>>
>>>> Hi Steve,
>>>>
>>>> I use Redhat 8.0 on a SMP P3 machine, I have no
>>>> problem with running the
>>>> sample_be code. I can also run the tcp_rmtlog_be and
>>>> udp_rmtlog_be
>>>> successfully. I suggest you check out the latest
>>>> evlog code from cvs, it has
>>>> all the POSIX_LOG_PRINTF defined in all the kernels'
>>>> evl_log.h.
>>>>
>>>> I did a search for umodsi3 in /usr/lib/libevl.so.1
>>>> and /lib/i686/libc.so.6
>>>> using "nm /lib/i686/libc.so.6 |grep umodsi3", but
>>>> cannot find any.
>>>>
>>>> Are you using an IA64?
>>>>
>>>> Thanks,
>>>> -Zhu Yi
>>>>
>>>
>>>
>>>
>>> =====
>>> ----------------------------------------------------------
>>> Steve Woodruff, N9OH @ 42.18N 88.34W, [email protected]
>>>
>>> __________________________________________________
>>> Do you Yahoo!?
>>> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
>>> http://mailplus.yahoo.com
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
>>> is essential in establishing user confidence by providing assurance 
>>> of authenticity and code integrity. Download our Free Code Signing 
>>> guide:
>>> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
>>> _______________________________________________
>>> evlog-developers mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/evlog-developers
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
>> is essential in establishing user confidence by providing assurance of 
>> authenticity and code integrity. Download our Free Code Signing guide:
>> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
>> _______________________________________________
>> evlog-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/evlog-developers
>>
>>
>> -------------------------------------------------------
>> This SF.NET email is sponsored by: Thawte.com
>> Understand how to protect your customers personal information by 
>> implementing
>> SSL on your Apache Web Server. Click here to get our FREE Thawte 
>> Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
>> _______________________________________________
>> evlog-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/evlog-developers
>>
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: Thawte.com
> Understand how to protect your customers personal information by 
> implementing
> SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
> Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
> _______________________________________________
> evlog-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/evlog-developers
> 


-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en