Skip site navigation (1) Skip section navigation (2)

Re: Re: undefined reference to _sys_nerr

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Enrique Perez Terron <enrique(dot)perez(dot)terron(at)Teknometri(dot)no>
Cc: pgsql-ports(at)postgresql(dot)org, juhan(at)suhkur(dot)cc(dot)ioc(dot)ee
Subject: Re: Re: undefined reference to _sys_nerr
Date: 2000-06-23 16:20:45
Message-ID: Pine.LNX.4.21.0006230243470.13792-100000@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-ports
Enrique Perez Terron writes:

> If libc does not have sys_errlist, where does strerror() get its data from? 

I think the coding in elog.c and exc.c is kind of pointless (other
locations happily use strerror indiscriminately) and obviously not
portable. It should probably be changed.

> Should we rather rely on strerror to check the validity of the argument,
> and output the alternative string only if strerror returns a null pointer 
> or a pointer to an empty string?

strerror should always return some error message, even if the argument
isn't valid. That's its whole point, versus using sys_errlist[errno]
(which is probably not portable either).


> Juhan Ernits <Juhan(at)suhkur(dot)cc(dot)ioc(dot)ee> wrote:
> >Hello! 
> >
> >System is NT4 SP6, cygwin 1.1, gcc 2.95.2, PG7RC2. 
> >Having fixed the dllmain problem, I got the following one: 
> >The step that assembles postgres.exe fails with the following messages: 
> >
> >utils/SUBSYS.o(text+0x42de7):elog.c: undefined reference to '_sys_nerr' 
> >utils/SUBSYS.o(text+0x437b3):exc.c: undefined reference to '_sys_nerr' 
> >collect2: ld returned 1 exit status 
> >make[1]: *** [postgres] Error 1
> >... 


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e(at)gmx(dot)net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


In response to

pgsql-ports by date

Next:From: Tatsuo IshiiDate: 2000-06-25 02:46:20
Subject: Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!
Previous:From: Ryan KirkpatrickDate: 2000-06-20 23:15:25
Subject: Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group