generates values for 'name' and/or 'proto' that cause the
failure?
My search for prior reports of failure at line 330 found
a mention of problems at line 331.
Well, at any rate, if someone could point me down the
correct path on this i would appreciate it.
pete jordan
x2164 -> mailcity.com
-> equals at symbol
--
--
http://mail.python.org/mailman/listinfo/python-list
he features that you
> want compiled in. Without thread support, sockets din't work, so it
> looks like you need to configure threads in. IIRC you do this by editing
> the Modules.? file.
> regards
> Steve
hi Steve,
Here's a cut down version of the compilation line for
socketmodule.c which contains the 'socket_getservbyname'
code:
gcc -pthread -DNDEBUG ...
-c /usr/src/Python-2.4/Modules/socketmodule.c
-o build/temp.linux-i686-2.4/socketmodule.o
Is '-pthread' the type of thread i need?
I'm still curious why only the call with one argument to
'socket.getservbyname' fails while the two other calls
which pass two arguments don't fail.
Any ideas?
pete jordan
x2164 at
mailcity com
--
--
http://mail.python.org/mailman/listinfo/python-list
found
>>>
From my /etc/services file:
daytime 13/tcp
daytime 13/udp
I was trying to use gdb to watch the function
socket_getservbyname, from Modules/socketmodule.c,
execute but i'm not sure how to set the gdb 'break' for
a function in a module that isn't imported at the time
i start python in gdb.
Hints welcome. ;-)
pete jordan
x2164 at
mail.city
--
--
http://mail.python.org/mailman/listinfo/python-list
probably right about there being a difference
in the behaviour of getservbyname between libc 2.2.5 and
and libc-2.3.3 given the differences in man pages and
observed return values. I'll try and compare the libcs'
getservbyname codes and let you know a little later in
the day.
I wonder if the developers wanted to tie the python source
code so closely to a glibc version and possibly gnu-libc
specific?
pete jordan
x2164 at mailcityDOTcom
miami, florida
--
--
http://mail.python.org/mailman/listinfo/python-list
ions of getservbyname plus some references to nss and
nis versions of getservbyname. Of course its also possilble
that where i said "What i believe happens" at the beginning
of this paragraph could be read as "I'm confused about what
happens" and i don't mean that as critic of glibc.
Marc, it is possible that there was a change between
glibc-2.2.4 and 2.2.5 that would account for the
difference in behaviour. I think i'll write a little
test program in C to check out getservbyname's return
values in a little more controled environment. I'll
post the results tomorrow.
pete jordan
x2164 mailcity com
--
--
http://mail.python.org/mailman/listinfo/python-list
ode around the call to
getservbyname in Modules/socketmodule.c to test
for a call with the NULL argument would be
appropriate. Could you show the output from my
included program when NULL is passed as
an argument? Probably would be good to know
what
message
> "service/proto not found" seems to only be generated upon
> failure of gibc's 'getservbyname' could it be that
> 'PyArg_ParseTuple(args, "s|s:getservbyname", &name, &proto)'
> generates values for '
