Dne 31.03.09 18:21, Tom Lane napsal(a):
Zdenek Kotala <zdenek.kot...@sun.com> writes:
Yeah correct, I overlooked that optreset is also defined as a extern.
There is updated patch.
On looking at this I still can't see how it's not broken. You are
effectively assuming that getopt_long.c must define those variables.
No I assuming that when we use getopt_long from libc then libc already
has these variables defined. It must.
But surely getopt_long.c should be assuming that getopt.c defines them.
Aren't we likely to end up with the situation that everyone is
extern'ing them?
Yeah, getopt_long assumes that optind, opterr and so on are already
defined by getopt. If you look in current implementation in BDS you can
see that there is getopt_internal() and getopt(), getopt_long are only
wrapper.
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdlib/getopt_long.c?rev=1.23;content-type=text%2Fplain
The main problem what I see here is that getopt and getopt_long works
together. Use one from system and one ported is not good idea. I think
best solution is to port new BSD version into postgreSQL and use both
function from libc version or ported versin. Mixing then is risky.
See also e.g. initdb.c, there is declaration of opterr...
What appears to me to be happening is that Solaris' linker is failing to
merge global variable definitions when it should (must) do so. We need
to find out why rather than solve it with a patch that will certainly
break other platforms.
Linker cannot do it in general. Libc contains these variables and
compiled code points to them. When you declare them again into your
application you override them but only for your application, not for libc.
If you can't come up with a real solution, we might have to do this
with "#ifndef SOLARIS" or something similar.
I prefer another solution then this, but it is also possible.
Personally prefer to port new getopt_long. It is benefit also for win users.
Zdenek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
