Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re: Perl5 on Linux/MIPS #1194

Closed
p5pRT opened this issue Feb 17, 2000 · 2 comments
Closed

Re: Perl5 on Linux/MIPS #1194

p5pRT opened this issue Feb 17, 2000 · 2 comments

Comments

@p5pRT
Copy link

p5pRT commented Feb 17, 2000

Migrated from rt.perl.org#2163 (status was 'resolved')

Searchable as RT2163$

@p5pRT
Copy link
Author

p5pRT commented Feb 17, 2000

From domo@computer.org

At 15​:16 -0800 2000-02-04, Erik Van Coops-Lotspeich wrote​:

My goal is to get Perl 5.00503 properly running on a Cobalt RaQ 2
which runs Linux 2.0.34 kernel on a MIPS R3000 processor. ...

Hi, Erik. Sorry for the belated reply. I'm copying this to perlbug
so that it gets a tracking number.

The problem is that I have a server written in Perl that needs to
execute the "socket()" function. When I try to run this program, Perl
comes back with​:

socket​: Protocol not supported at progname.pl line xxx

Hmmm. I'd expect something like the Qube to sport a perl which had
been well thrashed in terms of its networking abilities. Oh, well.
Try replacing symbols (you are using symbols, aren't you, not numeric
constants which happen to work elsewhere?) like AF_INET with numeric
constants taken from sys/socket.h, and see if that makes the problem
go away. If it does, write a program that displays the suspect
constants, and see if they're wrong​:

perl -MSocket -le 'print AF_INET' # trivial example of such a program

If they are wrong, the problem's something to do with the way the
Socket module (see ext/Socket/Socket.xs) is grabbing the constants.

At this stage it's worth checking whether the latest development
version of perl (<http​://www.cpan.org/src/devel.tar.gz >) fixes the
problem. If it does, work out how, and patch up your copy of
5.005_03 source. If it doesn't, you need to sort out the problem
yourself (and please tell us what you had to do).

If everything looks OK, go in with a debugger, and find out what's
getting passed when PerlSock_socket() (actually socket()) is called
in pp_sys.c. Given the error you're seeing, I'd expect the arguments
to look screwy. Your mission, should you choose to accept it, is to
find out where they get screwed, fix it, and send a patch.

I have built Perl successfully many times on Intel machines running
Linux, but this MIPS machine has me stumped.

I've no experience MIPS, but I seem to recall that it is/used to be
the case that the processors could use big- or little-endian byte
ordering at the OS implementor's whim. Add to this network byte
ordering, which may or may not differ from either, and there's scope
for confusion and bugs. If programs other than perl can create and
use sockets happily, it's conceivable that something's up with htonl
family of conversion macros that perl's finding. That said, if it's
the socket() call that's failing, IP addresses don't enter the
picture.

--
Dominic Dunlop

@p5pRT
Copy link
Author

p5pRT commented Feb 21, 2000

From [Unknown Contact. See original ticket]

At 11​:45 +0100 2000-02-17, Dominic Dunlop wrote​:

Try replacing symbols (you are using symbols, aren't you, not
numeric constants which happen to work elsewhere?) like AF_INET with
numeric constants taken from sys/socket.h, and see if that makes the
problem go away.

He WAS using numeric constants. Rewriting them symbolically fixed
the problem. This bug report can be closed now. (I can't find the
bug report at http​://bugs.perl.org/pbdb.cgi?req=search, which seems
to have nothing after the 13th, so I'm sending this placeholder to
the list.)

--
Dominic Dunlop

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant