Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Nov 2010 23:09:48 +0300
From:      "Grigory Rechistov" <ggg_mail@inbox.ru>
To:        FreeBSD-gnats-submit@FreeBSD.org
Subject:   ports/152306: devel/binutils create binary incompatible kernel modules
Message-ID:  <E1PIRr8-0000JS-00.ggg_mail-inbox-ru@smtp6.mail.ru>
Resent-Message-ID: <201011162020.oAGKK70Z091119@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         152306
>Category:       ports
>Synopsis:       devel/binutils create binary incompatible kernel modules
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-ports-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Nov 16 20:20:06 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator:     Grigory Rechistov
>Release:        FreeBSD 8.1-STABLE i386
>Organization:
>Environment:
System: FreeBSD atakua.doesntexist.org 8.1-STABLE FreeBSD 8.1-STABLE #3: Wed Oct 20 02:06:12 MSD 2010 root@atakua.doesntexist.org:/usr/obj/usr/src/sys/INTOX i386


	
>Description:
	When one has devel/binutils port installed and the $PATH is 
configured the way the utilities from this port take precedence over the 
system ones (from /usr/bin)  it is possible that kernel modules build 
from port system are binary incompatible with kernel and thus cannot be 
loaded and used. I experienced this issue with cuse4bsd-kmod and 
Virtualbox kernel modules.

See ports/151603 for example.

>How-To-Repeat:
1) Set your $PATH the way thet /usr/local/bin is the first entry in it: 
export PATH=/usr/local/bin:$PATH
2) Install virtualbox-ose with virtualbox-ose-kmod from ports.
3) Try to load the kernel module vboxdrv.ko
4) You'll see messages on undefined symbols
5) Try to build, install and them load cuse4bsd.ko from ports - it won't 
create any proper /dev/cuse devices expected from this kernel module

>Fix:
1) Deinstall devel/binutils before building kernel modules
or
2) Change $PATH so that system binutils are found, not the ones from the 
port

The actually fixed situation should either allow to build _usable_ 
kernel modules with any binutils in use, or automatically detect the 
correct ones, or at least warn a user about possible issues.


>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1PIRr8-0000JS-00.ggg_mail-inbox-ru>