Linker error - compiling wget

[Hrishikesh Murali]

Hi,

I'm quite new to minix. I am trying to compile 'wget' on my minix system. Initially, I had a few errors which I could easily solve. But now, the linker gives me errors as shown in http://pastebin.com/Yct7aUQB.

When i googled it up, it says that I should include the gcc libraries in the makefile:

LIBS = -lc -gcc

I included this option in the Makefile of wget, but even then the errors persist. Am I missing something here, or is there a workaround for the same?

--
Thanks and Regards,
Hrishikesh Murali

[Jorn van Engelen]

Hi,

I experienced the same errors some time ago.

I think I solved these errors by recompiling the gnu-libraries, so I
figure these errors come from the fact that you didn't recompile the
gnu-libraries when you recompiled the system. Solution: recompile
gnu-libraries:

# cd /usr/src
# make gnu-libraries

Hope it helps.

With kind regards,
Jorn van Engelen

> --
> You received this message because you are subscribed to the Google
> Groups "minix3" group.
> To post to this group, send email to min...@googlegroups.com.
> To unsubscribe from this group, send email to
> minix3+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/minix3?hl=en.

[Hrishikesh Murali]

Hi,

On Sun, Mar 20, 2011 at 5:13 PM, Jorn van Engelen <spa...@quzart.com> wrote:

so I figure these errors come from the fact that you didn't recompile the gnu-libraries when you recompiled the system.

Thanks, I'll try it out. But one thing, I have never recompiled the system, this is a fresh install of minix3.

[Jorn van Engelen]

Hi,

On 03/20/2011 12:46 PM, Hrishikesh Murali wrote:
> Hi,
>
> On Sun, Mar 20, 2011 at 5:13 PM, Jorn van Engelen <spa...@quzart.com
> <mailto:spa...@quzart.com>> wrote:
>
> so I figure these errors come from the fact that you didn't
> recompile the gnu-libraries when you recompiled the system.
>
>
> Thanks, I'll try it out. But one thing, I have never recompiled the
> system, this is a fresh install of minix3.

Ok, then I was probably wrong ... but I think it's still worth a shot.

Looking at your message again: if you want to compile with the gcc
libraries, shouldn't it be:

LIBS = -lc -lgcc

instead of

LIBS = -lc -gcc

[Hrishikesh Murali]

Hi,

On Sun, Mar 20, 2011 at 5:31 PM, Jorn van Engelen <spa...@quzart.com> wrote:

Looking at your message again: if you want to compile with the gcc libraries, shouldn't it be:

   LIBS = -lc -lgcc

instead of

   LIBS = -lc -gcc

I thought all libraries to be used during compilation are to be prefixed by a '-l'.

Anyway, I tried "LIBS = -lc -gcc" also, but with no success. :-( The same errors remain.

[Jorn van Engelen]

Hi,

On 03/20/2011 01:09 PM, Hrishikesh Murali wrote:
> I thought all libraries to be used during compilation are to be prefixed
> by a '-l'.

Correct, but in your first message you said you were using
'LIBS = -lc -gcc', without the 'l'.

[Hrishikesh Murali]

Hi,

On Sun, Mar 20, 2011 at 5:44 PM, Jorn van Engelen <spa...@quzart.com> wrote:

Correct, but in your first message you said you were using
'LIBS = -lc -gcc', without the 'l'.

Oops, that was a typo. Sorry.

[Hrishikesh Murali]

Hi,

On Sun, Mar 20, 2011 at 5:13 PM, Jorn van Engelen <spa...@quzart.com> wrote:

Solution: recompile gnu-libraries:

Recompiling the gnu-libraries didn't work :-(

I found libgcc.a in '/usr/pkg/gcc44/lib/gcc/i686-pc-minix/4.4.3/libgcc.a'. So I copied this library file to /usr/lib and tried with '-lgcc' option. Didn't succeed.

I copied the gcc command which was produced from the Makefile to obtain the final wget executable, and I modified it with the path of libgcc.a:

# cd wget-1.12/src
# gcc  -O2 -Wall -L/usr/pkg/gcc44/lib/gcc/i686-pc-minix/4.4.3 -lgcc -o wget cmpt.o connect.o convert.o  cookies.o ftp.o css.o  css-url.o ftp-basic.o ftp-ls.o  hash.o host.o html-parse.o  html-url.o http.o init.o log.o  main.o netrc.o progress.o  ptimer.o recur.o res.o retr.o  snprintf.o spider.o url.o  utils.o exits.o build_info.o   version.o ftp-opie.o gen-md5.o ../lib/libgnu.a ../md5/libmd5.a

Even now, no success! Same error persists.

[Jeff Pohlmeyer]

LIBS = -lc -lgcc -lm

On Sun, Mar 20, 2011 at 10:11 AM, Hrishikesh Murali wrote:

> Even now, no success! Same error persists.

Just a wild guess, but maybe try adding -lm

LIBS = -lc -lm -lgcc

- Jeff

[Hrishikesh Murali]

Hi,

On Sun, Mar 20, 2011 at 8:46 PM, Jeff Pohlmeyer <yetanot...@gmail.com> wrote:

LIBS = -lc -lgcc -lm

Nope, doesn't work still.

I tried doing 'make gnu-includes' also, but with no progress. Do I need to install some extra libraries or something?

[Ivan Gualandri]

Hi, 

the fact is that actualy wget is not working. 

i tried to compile it, and managed also to compile it, but it still doesn't work.

I don't rememeber how to made it compile (i'll check tomorrow).

Tomorrow i check how to make it compile and paste the solution. 

Then we must understand why it doesn't work :) (It has a memory dump error). 

Bye,

Ivan

--

You received this message because you are subscribed to the Google Groups "minix3" group.
To post to this group, send email to min...@googlegroups.com.
To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/minix3?hl=en.

--
"elen sila lumenn omentielvo"

[Murray]

What version of wget are you trying to compile.
I have tried to compile wget 1.12 from ftp.gnu.

However I get a different error in regards to MSG_PEEK not being
defined, which I am tracking down at the moment.

I was wondering if the order of library flags is important, ie -lm
before -lgcc,

finaly did you run ./configure before make?

On Mar 21, 7:07 am, Hrishikesh Murali <hrishikeshmural...@gmail.com>
wrote:
> Hi,

[Murray]

Ok I had problems with wget-1.12 so I have tried with wget-1.5 and
that works, provided you run ./configure --host=minix
minix now uses fetch instead of wget, any reason you want to use wget?

[Hrishikesh Murali]

Hi,

On Mon, Mar 21, 2011 at 4:30 AM, Murray <muzz...@hotmail.com> wrote:

What version of wget are you trying to compile.

wget-1.12
 

However I get a different error in regards to MSG_PEEK not being
defined, which I am tracking down at the moment.

For the error with regard to MSG_PEEK, I just added the following lines:

#ifndef MSG_PEEK
#define MSG_PEEK 0
#endif

Though this is just a very naive workaround, I did this so that it would alteast compile. I thought it wouldn't be much of a problem since this solution was also used in http://bugs.php.net/44233.
 

I was wondering if the order of library flags is important, ie -lm
before -lgcc,

I don't think so. If there are a lot of libraries being used, then taking them one by one and linking them will only increase the time of linking as it has to read the library from disk (I/O) each time.

Since most of the system libraries are in /usr/lib, there is a good chance that the libraries are very closely allocated to each other on disk.

A better mechanism would be to read all the library functions' virtual addresses (generated by gcc) at one shot to main memory and then link them, therefore decreasing the time needed to link.

So I'm guessing gcc does this, but I may be wrong.
 

finaly did you run ./configure before make?

Yes, but I'll also try running ./configure with '--host=minix' option and see if there is some success. 

[Hrishikesh Murali]

Hi,

On Mon, Mar 21, 2011 at 5:22 AM, Murray <muzz...@hotmail.com> wrote:

minix now uses fetch instead of wget, any reason you want to use wget?

I wanted to port a small program onto pkgsrc. The first step is that it should atleast compile on the minix system. Therefore the compilation of wget from source.

[Hrishikesh Murali]

Hi,

I think this is a problem with my minix system. I tried compiling a simple C program:

FILE: test.c
-------------------------------------
#include <stdio.h>

int main(int argc, char **argv) {

int i = 1;
i++;
printf("i: %d\n",i);

return 0;

}
-------------------------------------

# gcc test.c -o test
/usr/lib/libc.a(fphook.o):fphook.o:(.text+0x2fa): undefined reference to `___nedf2'
/usr/lib/libc.a(ext_comp.o):ext_comp.o:(.text+0xb80): undefined reference to `___ltdf2'
/usr/lib/libc.a(ext_comp.o):ext_comp.o:(.text+0xbc0): undefined reference to `___muldf3'
/usr/lib/libc.a(ext_comp.o):ext_comp.o:(.text+0xbdb): undefined reference to `___floatunsidf'
/usr/lib/libc.a(ext_comp.o):ext_comp.o:(.text+0xbef): undefined reference to `___subdf3'
/usr/lib/libc.a(ext_comp.o):ext_comp.o:(.text+0xc0b): undefined reference to `___muldf3'
/usr/lib/libc.a(ext_comp.o):ext_comp.o:(.text+0xcba): undefined reference to `___floatunsidf'
/usr/lib/libc.a(ext_comp.o):ext_comp.o:(.text+0xce6): undefined reference to `___muldf3'
/usr/lib/libc.a(ext_comp.o):ext_comp.o:(.text+0xd03): undefined reference to `___floatunsidf'
/usr/lib/libc.a(ext_comp.o):ext_comp.o:(.text+0xd17): undefined reference to `___adddf3'
/usr/lib/libc.a(ext_comp.o):ext_comp.o:(.text+0xd60): undefined reference to `___eqdf2'
/usr/lib/libc.a(frexp.o):frexp.o:(.text+0x7a): undefined reference to `___muldf3'
/usr/lib/libc.a(ldexp.o):ldexp.o:(.text+0xb5): undefined reference to `___muldf3'
/usr/lib/libc.a(ldexp.o):ldexp.o:(.text+0x14e): undefined reference to `___muldf3'
/usr/lib/libc.a(ldexp.o):ldexp.o:(.text+0x170): undefined reference to `___eqdf2'
collect2: ld returned 1 exit status
#

My minix 3.1.9 system is a fresh install. I updated my pkgin package list, then installed gcc, nano, vim and other small programs using pkgin. The other thing I did was I got the latest sources of pkgsrc using make 'make pkgsrc-create' in /usr.

Is there something else I need to do?

[Ivan Gualandri]

did you tried to do: 

make gnu-libraries gnu-includes ?

(in /usr/src ) 

They are needed everytrime you update a system. 

Bye,

Ivan

--

You received this message because you are subscribed to the Google Groups "minix3" group.
To post to this group, send email to min...@googlegroups.com.
To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/minix3?hl=en.

[Jorn van Engelen]

Hi,

On 03/21/2011 06:12 AM, Hrishikesh Murali wrote:
> I was wondering if the order of library flags is important, ie -lm
> before -lgcc,
>
>
> I don't think so. If there are a lot of libraries being used, then
> taking them one by one and linking them will only increase the time of
> linking as it has to read the library from disk (I/O) each time.
>
> Since most of the system libraries are in /usr/lib, there is a good
> chance that the libraries are very closely allocated to each other on disk.
>
> A better mechanism would be to read all the library functions' virtual
> addresses (generated by gcc) at one shot to main memory and then link
> them, therefore decreasing the time needed to link.
>
> So I'm guessing gcc does this, but I may be wrong.

The order of library flags is actually very important. This message
explains it:
http://groups.google.com/group/minix3/msg/f2142b811cfd963e

The explanation begins with:
"Perhaps you haven't ran into this problem, but it took me a long time
to figure out. Outline is: order does matter when linking in static
libraries.

Situation
=====
[...]

[Murray]

With regards to MSG_PEEK I found that the value should be 0x02 as it
part of an enumerated type
required by recv in connect.c
Having defined MSG_PEEK I recompiled and _IN6_ARE_ADDR_EQUAL in host.o
not being defined so I am
tracking where that is at the moment.

On Mar 21, 6:12 pm, Hrishikesh Murali <hrishikeshmural...@gmail.com>
wrote:
> Hi,

>
> On Mon, Mar 21, 2011 at 4:30 AM, Murray <muzzd...@hotmail.com> wrote:
> > What version of wget are you trying to compile.
>
> wget-1.12
>
> > However I get a different error in regards to MSG_PEEK not being
> > defined, which I am tracking down at the moment.
>
> For the error with regard to MSG_PEEK, I just added the following lines:
>
> #ifndef MSG_PEEK
> #define MSG_PEEK 0
> #endif
>
> Though this is just a very naive workaround, I did this so that it would
> alteast compile. I thought it wouldn't be much of a problem since this

> solution was also used inhttp://bugs.php.net/44233.

[Antoine LECA]

Murray wrote:
> I was wondering if the order of library flags is important, ie -lm
> before -lgcc,

Background: gcc automatically adds -lc -lgcc at the end of the link
command line; use -v (or LDFLAGS=-v) to have it on screen.

However, there are sometimes some dependancies from code inside libgcc.a
which depends from libc.a, so are not resolved correctly and may result
in errors. My guess is that, it is the case with wget.

An ugly hack yet effective workaround is to use explicitly -lc -lgcc on
the GCC command line, which results in exec'ing
ld [....] -lc -lgcc -lc -lgcc
so any unresolved references from first reading of libgcc.a can be
resolved by the second reading of libc.a... Yes this is a kludge.

A better solution is to use GNU ld features, like grouping; so the ld
line shows as
ld [....] -( -lc -lgcc -)
[or uses --begin-group/--end-group instead of -( / -) which are easy to
type on command line; the effect is the same.]
I do not know if the gcc used by Minix uses that

Another point: libm.a in MINIX is completely dummy, it has no effect at
all, it is provided just to satisfy old Makefiles from PDP11 era which
insist to provide explicit reference to it.

Hope it helps

Antoine

[Murray]

I can compile and run wget-1.12 succesfully.
All that is needed is to add
#define MSG_PEEK 0x02

and

./configure --disable-ipv6
make
make install

if you are still getting errors try
# cd /usr/src
# make clean world gnu-libraries gnu-includes
which will rebuild your system from scratch including all the gcc
libraries and include files

On Mar 21, 10:57 pm, Antoine LECA <Antoine.Lec...@gmail.com> wrote:
> Murray wrote:
> > I was wondering if the order of library flags is important, ie -lm
> > before -lgcc,
>
> Background: gcc automatically adds -lc -lgcc at the end of the link
> command line; use -v (or LDFLAGS=-v) to have it on screen.

explains when I look at the Makefile why I dont see these

> However, there are sometimes some dependancies from code inside libgcc.a
> which depends from libc.a, so are not resolved correctly and may result
> in errors. My guess is that, it is the case with wget.
>
> An ugly hack yet effective workaround is to use explicitly -lc -lgcc on
> the GCC command line, which results in exec'ing
>    ld [....] -lc -lgcc -lc -lgcc
> so any unresolved references from first reading of libgcc.a can be
> resolved by the second reading of libc.a... Yes this is a kludge.
>
> A better solution is to use GNU ld features, like grouping; so the ld
> line shows as
>    ld [....] -( -lc -lgcc -)
> [or uses --begin-group/--end-group instead of -( / -) which are easy to
> type on command line; the effect is the same.]
> I do not know if the gcc used by Minix uses that
>
> Another point: libm.a in MINIX is completely dummy, it has no effect at
> all, it is provided just to satisfy old Makefiles from PDP11 era which
> insist to provide explicit reference to it.

I guess libm.a is the math library? making -lm redundant

> Hope it helps
>
> Antoine

[Hrishikesh Murali]

Hi,

I finally could get wget successfully compiled. I'm not sure in any case, but it might be a problem with the gcc44 package which pkgin downloaded from the repository and installed.

This time, the only difference I did this time was to manually download the gcc44 package from ftp://ftp.minix3.org/pub/minix/packages/3.1.8/i386/All/gcc44-4.4.3.tgz and copy it to /usr/var/db/pkgin/cache/. Then, when I compiled wget, it worked fine without any linker error!

In all the previous attempts, i would do:

# pkgin update
# pkgin install gcc44

And compilation of wget never used to work successfully!

One more thing I noticed in the previous attempts:
# ./configure --disable-ipv6
---------snip------------
checking for size of short ... 0
checking for size of int ... 0
checking for size of long ... 0
---------snip------------

Wierd isn't it?! I used to ignore that.

But now, when I did the same, the output was:
# ./configure --disable-ipv6
---------snip------------
checking for size of short ... 2
checking for size of int ... 4
checking for size of long ... 4
---------snip------------

I want to know how to see which repository pkgin is updating its local database and installing the packages from. How do I do that, and for some wierd reason if I want to change it, where would I need to change?

[Vivek Prakash]

Hi,

> I finally could get wget successfully compiled. I'm not sure in any case,
> but it might be a problem with the gcc44 package which pkgin downloaded from
> the repository and installed.
>
> This time, the only difference I did this time was to manually download the
> gcc44 package from
> ftp://ftp.minix3.org/pub/minix/packages/3.1.8/i386/All/gcc44-4.4.3.tgz and
> copy it to /usr/var/db/pkgin/cache/. Then, when I compiled wget, it worked
> fine without any linker error!

I attempted porting wget to Minix in January but got stuck in linker
errors. The error that i used to get was related to 'libidn.a' , and
when i compiled without it, running wget used to give core dumps.
If you didn't get any linker error, i may have been doing something
wrong and i will retry by setting up the configurations file in pkgsrc
tree and rebuilding wget.

> I want to know how to see which repository pkgin is updating its local
> database and installing the packages from. How do I do that, and for some
> wierd reason if I want to change it, where would I need to change?

The repository file is located at /usr/pkg/etc/pkgin/repositories.conf
. pkgin updates the database from the minix3 repository itself.

I am not sure what '--disable-ipv6' does ? Any idea ? I remember that
'CONFIGURE_ARGS+=--disable-ipv6' is already there in wget/options.mk
and yet i had problem in building wget.

~
Vivek Prakash

[Hrishikesh Murali]

Hi,

On Thu, Mar 24, 2011 at 6:53 AM, Vivek Prakash <vivek....@gmail.com> wrote:

I attempted porting wget to Minix in January but got stuck in linker
errors. The error that i used to get was related to 'libidn.a' , and
when i compiled without it, running wget used to give core dumps.
If you didn't get any linker error, i may have been doing something
wrong and i will retry by setting up the configurations file in pkgsrc
tree and rebuilding wget.

Hmmm, I didn't get any such error. For me, even though wget compiles successfully, it doesn't run properly!

# wget google.com
--2011-03-24 09:46:23-- http://google.com/
Connecting to 192.16.3.254:8080... Connected
Proxy request sent, awaiting response... Read error (Function not implemented) in headers.
Retrying
------------------ SNIP --------------------------

And it retries and fails with the same errors again.

The exact same wget query works fine from my host machine running linux.
 

[Vivek Prakash]

> Hmmm, I didn't get any such error. For me, even though wget compiles
> successfully, it doesn't run properly!

> The exact same wget query works fine from my host machine running linux.

The possible reason is that wget got compiled by taking some function
prototype from headers but they are not implemented anywhere in the
Minix. The output from wget command reflects this. You can use a
debugger to find out where wget is crashing by finding which function
is not implemented.

~
Vivek Prakash

[Gautam B.T.]

On Thu, Mar 24, 2011 at 9:54 AM, Hrishikesh Murali
<hrishikes...@gmail.com> wrote:
> Hi,
>
> On Thu, Mar 24, 2011 at 6:53 AM, Vivek Prakash <vivek....@gmail.com>
> wrote:
>>
>> I attempted porting wget to Minix in January but got stuck in linker
>> errors. The error that i used to get was related to 'libidn.a' , and
>> when i compiled without it, running wget used to give core dumps.
>> If you didn't get any linker error, i may have been doing something
>> wrong and i will retry by setting up the configurations file in pkgsrc
>> tree and rebuilding wget.
>
> Hmmm, I didn't get any such error. For me, even though wget compiles
> successfully, it doesn't run properly!
>
> # wget google.com
> --2011-03-24 09:46:23-- http://google.com/
> Connecting to 192.16.3.254:8080... Connected
> Proxy request sent, awaiting response... Read error (Function not
> implemented) in headers.
> Retrying
> ------------------ SNIP --------------------------
>
> And it retries and fails with the same errors again.
>

Have you looked at changes made to compile the older wget package from
bigports[1]?

[1] https://gforge.cs.vu.nl/gf/project/minix/scmsvn/?action=browse&path=%2Ftrunk%2Fbigports%2F
--
Gautam

[Antoine LECA]

Vivek Prakash wrote:
> The possible reason is that wget got compiled by taking some function
> prototype from headers but they are not implemented anywhere in the
> Minix.

As in, there are some functions which prototypes are provided by Minix
but there are no implementation?
I know such a case was detected some months ago (tc{get,set}pgrp), but I
consider it a bug and it ought to be reported, at the very least to
allow some tracking.

Or, do you mean wget hardcodes some prototypes which are (supposedly)
available with the "mainstream" operating systems (read: Linux), while
not provided by MINIX?
In such a case, besides being a blatant failure of the autofoobar
process, it looks like a bug to be reported "upstream", doesn't it?

> You can use a debugger to find out where wget is crashing by finding
> which function is not implemented.

Ahem. There are no shared libraries thus no dynamic linking in MINIX. So
things are at least easier in this area: either a function is not
implemented, and linking fails (with a helpful error message). Or the
function does have an implementation, and if there is some crash, it is
not because of some function missing, rather because of a bug.

Antoine

[Vivek Prakash]

Hi,

> Or, do you mean wget hardcodes some prototypes which are (supposedly)
> available with the "mainstream" operating systems (read: Linux), while
> not provided by MINIX?
> In such a case, besides being a blatant failure of the autofoobar
> process, it looks like a bug to be reported "upstream", doesn't it?

As of now, i haven't seen any hardcoded function prototype in the
source code of wget.

> Ahem. There are no shared libraries thus no dynamic linking in MINIX. So
> things are at least easier in this area: either a function is not
> implemented, and linking fails (with a helpful error message). Or the
> function does have an implementation, and if there is some crash, it is
> not because of some function missing, rather because of a bug.

Yes, you are right. My inexperience caused me to give a wrong
conclusion. However, if it is a bug, what may be the possible cause
of it ?

~
Vivek Prakash

[Murray]

The big question is what is wget failing at compared to in linux, I
have wget-1.5 compiled and working in minix 3.1.8, ie it downloads
google.com/index.html
how ever even as wget-1.12 compiles in minix 3.1.8 it will not
download google.com/index.html but will download from other addresses.

ipv6 has to be disabled for wget-1.12 to work in minix, could this be
a problem?

I also noticed that wget in linux to google.com results in a
redirection, this is probably the first place to look for bugs

On Mar 24, 7:23 pm, "Gautam B.T." <gautam...@gmail.com> wrote:
> On Thu, Mar 24, 2011 at 9:54 AM, Hrishikesh Murali
>
>
>
>
>
>
>
>
>
> <hrishikeshmural...@gmail.com> wrote:
> > Hi,
>

> > On Thu, Mar 24, 2011 at 6:53 AM, Vivek Prakash <vivek.cs.i...@gmail.com>

> > wrote:
>
> >> I attempted porting wget to Minix in January but got stuck in linker
> >> errors. The error that i used to get was related to 'libidn.a' , and
> >> when i compiled without it, running wget used to give core dumps.
> >> If you didn't get any linker error, i may have been doing something
> >> wrong and i will retry by setting up the configurations file in pkgsrc
> >> tree and rebuilding wget.
>
> > Hmmm, I didn't get any such error. For me, even though wget compiles
> > successfully, it doesn't run properly!
>
> > # wget google.com

> > --2011-03-24 09:46:23--http://google.com/

> > Connecting to 192.16.3.254:8080... Connected
> > Proxy request sent, awaiting response... Read error (Function not
> > implemented) in headers.
> > Retrying
> > ------------------ SNIP --------------------------
>
> > And it retries and fails with the same errors again.
>
> Have you looked at changes made to compile the older wget package from
> bigports[1]?
>

> [1]https://gforge.cs.vu.nl/gf/project/minix/scmsvn/?action=browse&path=%...
> --
> Gautam

[Murray]

An update to my last post.

The solution to getting wget working in minix is to use an older
version that does not need MSG_PEEK in connect.c

This is because flags have not yet been implemented in src/lib/libc/ip/
recvfrom.c

Another solution would be to add flag support for recfrom.c so
wget-1.12 will work.

[Manoj]

HI,
I am getting the wierd linker errors. I tried porting vipw and I am getting the same errors as hrishikesh .I tried recompiling and got the same error again.

Any idea what to do ??

Regards,
Manoj

[Murray]

what kind of errors???