# Missing svr4_delete_socket for kernel modules SVR4 & STREAMS



## ske (Mar 25, 2016)

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:


```
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.


----------



## SirDice (Mar 25, 2016)

It looks like this stuff hasn't been updated since the 4.0 era. Why do you need it?


----------



## ske (Mar 25, 2016)

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 (Mar 25, 2016)

svr4 support went out (from FreeBSD) quite a few years back, if I remember correctly. Google it.


----------



## ske (Mar 27, 2016)

tingo said:


> svr4 support went out (from FreeBSD) quite a few years back, if I remember correctly. Google it.



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?


----------



## Juha Nurmela (Mar 27, 2016)

Maybe you have to compile them in. svr4.ko and streams.ko seem to be interlinked, loading one whines about the other missing 

Juha


----------



## ondra_knezour (Mar 27, 2016)

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.



Maybe trying to compile those modules statically into the kernel may works?


----------



## ondra_knezour (Mar 27, 2016)

Regarding the origin of the error message - https://svnweb.freebsd.org/base/head/sys/kern/link_elf.c?revision=295489&view=markup#l1186


----------



## ske (Mar 28, 2016)

ondra_knezour said:


> Regarding the origin of the error message - https://svnweb.freebsd.org/base/head/sys/kern/link_elf.c?revision=295489&view=markup#l1186



Is there a way to search the sources? Google doesn't seem to find them. I have difficulty finding the elf_reloc() function, and the source of the svr4 module, to check them out.


----------



## ondra_knezour (Mar 28, 2016)

ske said:


> Is there a way to search the sources?


I am not aware of any "official" source search method, but you can for exmple grep in /usr/src or use search this repository on Github (may require account there)

See https://github.com/freebsd/freebsd/search?utf8=✓&q=elf_reloc and sys/modules/svr4/ and sys/compat/svr4/.


----------



## ske (Mar 28, 2016)

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.)


----------



## ske (Apr 2, 2016)

I submitted problem report 208464 for this.
PR 208464


----------



## ske (Apr 8, 2016)

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?


----------

