Re: linux-ipsec: Latest snapshot and 2.0.35

        Following up to my own post... I'm beginning to sound like a sttttutttter... :-)

Michael H. Warfield enscribed thusly:
> Richard Guy Briggs enscribed thusly:

> > > Richard Guy Briggs enscribed thusly:

> > > > Right. That is why it is encapsulated with #ifdef CONFIG_IPSEC. If I

> > Ok...I am guilty here of not regenerating the patches from my tree...I

> On to the next problem with modules in the latest snapshot... Gee

> It's compiling and linking the main kernel properly now but I'm

> RedHat 4.2:

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

> wittsend:/# insmod ipsec

> RedHat 5.1:

> [root@rebma /root]# insmod ipsec

> Ok... A show stopper on both versions is that reference to strcpy...

> On 5.1... Both htonl and ntohl are suppose to be macros (I

        I've tracked down all three unresolved symbols to the libkernel.a file in the freeswan lib directory and which is included in building the ipsec.o file. Is this library suppose to be referenced from modules in both kernel space and user space? We got a problem there if they are. I understand that some of the recent stuff with address conversion and parsing are at the heart of some of the routines in that directory. The ntohl and htonl problems are probably just a missing or changed header file when moving to glibc 6, and I'm looking into that one now. The reference to strcpy seems more problematical. It's referenced by several of the .c files in that directory but, aparently, is unavailable to a kernel module. This one affects both libc5 and glibc6 systems so I would guess a header file fix is not going to solve this one. Thoughts on a work around?

        Mike

-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (770) 925-8248   |  
http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!