Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 02 Apr 2016 07:16:26 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-i386@FreeBSD.org
Subject:   [Bug 208464] [svr4] svr4.ko fails to load due to not finding symbol svr4_delete_socket even though it is present in same module
Message-ID:  <bug-208464-10@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208464

            Bug ID: 208464
           Summary: [svr4] svr4.ko fails to load due to not finding symbol
                    svr4_delete_socket even though it is present in same
                    module
           Product: Base System
           Version: 10.2-RELEASE
          Hardware: i386
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs@FreeBSD.org
          Reporter: ske-89@pkmab.se
                CC: freebsd-i386@FreeBSD.org
                CC: freebsd-i386@FreeBSD.org

When I try to "kldload svr4.ko" I get this error:

        link_elf: symbol svr4_delete_socket undefined
        KLD svr4.ko: depends on streams - not available or version mismatch
        kldload: can't load svr4: No such file or directory

This would appear to say that streams.ko might need to be loaded before svr=
4.ko
to provide the symbol svr4_delete_socket. That is not correct, though. Load=
ing
streams.ko also complains that svr4_delete_socket is undefined.

Checking the revision histories and source code for svr4.ko and streams.ko,=
 I
noticed that svr4_delete_socket() was moved from streams.c to svr4_socket.c=
 in
July 2006. https://svnweb.freebsd.org/base?view=3Drevision&revision=3D160558

So now svr4_delete_socket is an internal symbol of the svr4.ko module.
So link_elf shouldn't need to import it at all when loading svr4.ko.
There seems to be some mixup regarding which module this symbol belongs to.

Next thing I noticed is that there is still an "EXPORT_SYMS=3Dsvr4_delete_s=
ocket"
in the Makefile for the streams module, where the symbol does no longer exi=
st.
And there is no such EXPORT_SYMS in the Makefile for the svr4 module, where=
 the
symbol currently lives. I would assume this should have been moved together
with the source code for svr4_delete_socket(), but was overlooked.
https://svnweb.freebsd.org/base/head/sys/modules/streams/Makefile?view=3Dma=
rkup
https://svnweb.freebsd.org/base/head/sys/modules/svr4/Makefile?view=3Dmarkup

I'm not experienced enough with FreeBSD kernel source to know for sure if t=
his
is really the whole story, but to me it seems like a good explanation for t=
he
bug. I don't see any other mention of svr4_delete_socket when searching the
source code, that would explain this symtom.

Can we get this fixed, so svr4.ko and streams.ko can be loaded again?

It seems a pity having such a simple bug preventing their use.

I'm not equipped to try to fix this myself, otherwise I would.

- I tried this out on FreeBSD-10.2-RELEASE-i386-bootonly.iso and
FreeBSD-10.1-RELEASE-i386-bootonly.iso.

The same problem occurs also with 8.0-RELEASE-i386-livefs.iso, except there=
 you
need to check dmesg to see the message from link_elf.

Given the explanation and date above, I would assume the same occurs in rel=
ease
7 too, but I didn't test it.

I have also discussed this in the forum thread
https://forums.freebsd.org/threads/55617/

I didn't find any previous problem reports about this.

There have been various forum discussions mentioning not being able to use
these modules on various releases, but not very detailed.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-208464-10>