Missing svr4_delete_socket for kernel modules SVR4 & STREAMS

S

ske

I'm trying out the following on a freshly downloaded and booted FreeBSD-10.2-RELEASE-i386-bootonly.iso:
kldload streams svr4

But I get this error for both of these modules:

Code: 
link_elf: symbol svr4_delete_socket undefined

How do I fix this?
Should I load something else first?
A quick grep didn't reveal any other module files with this symbol.
 
It looks like this stuff hasn't been updated since the 4.0 era. Why do you need it?
 
I have some very old binary-only programs (using streams) that I would like to test if they will perhaps run using this facility, in stead of keeping around the old systems where they reside currently.

If these modules are still being kept around in current versions of FreeBSD, shouldn't it be possible to load and use them, somehow?
 
tingo said:
svr4 support went out (from FreeBSD) quite a few years back, if I remember correctly. Google it.
Click to expand...

Yes, I googled and found one post from SirDice 2014 that said "it appears both SVR4 and IBCS2 are both still alive" (in FreeBSD)...
https://forums.freebsd.org/threads/46535/#post-266253

If these modules were not part of FreeBSD any more, why are they then still being shipped as part of it?

Anyway, I would just be curious to know more about what it means when kldload causes a complaint from link_elf about some symbol not being defined? I'm new to FreeBSD (but not new to Unix and kernels), and didn't find any man page for link_elf on this site, and the man page for kldload didn't mention this error. In what case would a module being shipped with FreeBSD cause this error? Is there something I, as the user, should have done to avoid such an error? Load some other module?
 
I think that this kind of question like "How to resurrect some historic code?" have better chance to get answered in the mailing lists. The freebsd-questions@, freebsd-stable@ and maybe even freebsd-hackers@ lists may be suitable for this one. See https://lists.freebsd.org/mailman/listinfo

Quick search reveals following in the BUGS section of kld(4):
If a custom entry point is used for a module, and the module is compiled
as an `ELF' binary, then kldload(8) fails to execute the entry point.
Click to expand...

Maybe trying to compile those modules statically into the kernel may works?
 
The function svr4_delete_socket() IS present in svr4_socket.c, even though link_elf complains that it can't find it.
https://svnweb.freebsd.org/base/head/sys/compat/svr4/svr4_socket.c?view=markup#l152

And svr4_socket.c is part of the svr4.ko module, according to its Makefile.
https://svnweb.freebsd.org/base/head/sys/modules/svr4/Makefile?view=markup

So why would loading svr4.ko try to relocate references to svr4_delete_socket(),
when that symbol is already present in that module?

I noticed that svr4_delete_socket() was moved from streams.c to svr4_socket.c
in 2006 (which is one of the most "recent" changes to that file), according to
the revision log.

But I also noticed that there is still an "EXPORT_SYMS=svr4_delete_socket" in the
Makefile for the streams module, where it does no longer exist.
https://svnweb.freebsd.org/base/head/sys/modules/streams/Makefile?view=markup

I would guess this is the error, or part of the error.

I don't know how to get it fixed, though.

(I don't have a system set up to compile it myself, either.)
 
I created a fix for the problem myself, and uploaded it to the problem report.

Now svr4.ko and streams.ko load fine, when I compile the fix locally. Probably for the first time in many years.

Fixing the problem was somewhat more complicated than I suggested earlier. There were more symbols that did not resolve properly, that had to be fixed too. And together they created a two-way dependency between these two modules, preventing both of them from being loaded no matter which one was loaded first. All probably originating from a code reorganization in 2006 where code was moved between these two modules. I had to move some more code to reduce the dependencies.

Will someone look into accepting my uploaded patch "automatically", or do I need to notify someone of it or do something more?

I also had some problems compiling the modules separately rather than compiling the whole system. It complained about not finding x86/endian.h and 7 other include files in the linked sub-directory machine/. I don't know if this is because of some missing setup that I a not aware of should be done before trying to compile separate modules? Or is this a genuine problem too in need of a fix?
 
You must log in or register to reply here.
Back
Top