Problem with VirtualBox, particularly with VBoxRT.so

Y

y2s82

I have been using VirtualBox for several years to run programs that simply cannot run in FreeBSD. It had been useful tool in that regard since it meant no more need to dual boot :)

After updating that 9-stable after the 9.1 release, however, my virtualbox won't run, complaining about kernel module not being loaded properly. Upon inspecting the dmesg, I see a line related to this:
Code: 
Shared object "libiconv.so.3" not found, required by "VBoxRT.so"
This is odd; I found the libiconv.so.3 in /usr/local/lib folder, so, as far as I can tell, it exists. I've tried recompiling emulators/virtualbox-ose, emulators/virtualbox-ose-kmod, as well as converters/iconv and converters/libiconv to no avail. I've also tried rebuilding said ports in clang and gcc. Neither worked. I've also re-updated the /usr/src and rebuild the world and kernel and that didn't resolve anything, either. What steps can I take to address this?
 
Thanks for the timely reply.

That did return some information, though it seems unrelated; it says a bunch of files for openjdk misses libz.so.4

Code: 
bootstrap-openjdk-r306764: /usr/local/bootstrap-openjdk/bin/idlj misses libz.so.4
bootstrap-openjdk-r306764: /usr/local/bootstrap-openjdk/bin/jar misses libz.so.4
bootstrap-openjdk-r306764: /usr/local/bootstrap-openjdk/bin/java misses libz.so.4
bootstrap-openjdk-r306764: /usr/local/bootstrap-openjdk/bin/javac misses libz.so.4
bootstrap-openjdk-r306764: /usr/local/bootstrap-openjdk/bin/javah misses libz.so.4
bootstrap-openjdk-r306764: /usr/local/bootstrap-openjdk/bin/javap misses libz.so.4
bootstrap-openjdk-r306764: /usr/local/bootstrap-openjdk/bin/native2ascii misses libz.so.4
bootstrap-openjdk-r306764: /usr/local/bootstrap-openjdk/bin/rmic misses libz.so.4
bootstrap-openjdk-r306764: /usr/local/bootstrap-openjdk/jre/bin/java misses libz.so.4
bootstrap-openjdk-r306764: /usr/local/bootstrap-openjdk/jre/lib/i386/libzip.so misses libz.so.4

Perhaps on an unrelated note, should I be worried about libz.so.4 and libzip.so? My guess is though that this wouldn't help me with VirtualBox...
 
Those are probably just from an old binary JDK package, not relevant to VirtualBox.

Forgive the obvious questions:

1. When rebuilding converters/libiconv, did you clean the port first?
2. What does ls -lh /usr/local/lib/libiconv.so.3 show?
3. Do you have any go-fast options in /etc/make.conf?
 
wblock@ said:
Those are probably just from an old binary JDK package, not relevant to VirtualBox.
Click to expand...
Alright. I'll deal with them later :) Thanks

wblock@ said:
Forgive the obvious questions:
Click to expand...
Do treat me like I'm oblivious because I really am haha.

wblock@ said:
1. When rebuilding converters/libiconv, did you clean the port first?
Click to expand...
I used portmaster -D -H to rebuild them. My understanding is that, unless given a flag (forget which one), it would always clean and uninstall before installing. Am I wrong in this assumption?

wblock@ said:
2. What does ls -lh /usr/local/lib/libiconv.so.3 show?
Click to expand...
It showed this:
Code: 
-r--r--r--  1 root  wheel   1.0M Jan 16 22:16 /usr/local/lib/libiconv.so.3
wblock@ said:
3. Do you have any go-fast options in /etc/make.conf?
Click to expand...
I have been using a custom /etc/make.conf, which I have taken and modified from this post. I've used it to toggle build of emulators/virtualbox-ose and emulators/virtualbox-ose-kmod in clang and gcc.
They are the following:
Code: 
WITHOUT_TEXLIVE_MKTEXLSR=true
WITH_NEW_XORG=true
WITH_KMS=true

# Don't forget this when using Jails and clang together
NO_FSCHG=

#
# PORTS: use clang unless gcc is explicitly required
#

#
# default to using clang for all port builds, with the following
# exceptions

# ports which will only build with the base system GNU compiler (4.2)
#
# the "make index" target also seems to need this, for some reason

.if target(index) | \
${.CURDIR:M*/devel/antlr*} | \
${.CURDIR:M*/devel/google-perftools* } | \
${.CURDIR:M*/graphics/ImageMagick* } | \
${.CURDIR:M*/graphics/opencv*} | \
${.CURDIR:M*/www/libxul*} | \
${.CURDIR:M*/x11/kdelibs4*} | \
${.CURDIR:M*/x11-toolkits/swt-devel*}
USE_GCC?=4.2
.endif

# ports which need *some* version of the GNU compiler (won't build with
# clang or have runtime issues if built with clang)
# use the highest version of gcc we have installed from ports (4.6)

.if ${.CURDIR:M*/accessibility/jovie*} | \
${.CURDIR:M*/accessibility/kdeaccessibility4*} | \
${.CURDIR:M*/audio/grip*} | \
${.CURDIR:M*/audio/mpg123*} | \
${.CURDIR:M*/audio/rosegarden*} | \
${.CURDIR:M*/databases/virtuoso*} | \
${.CURDIR:M*/emulators/virtualbox-ose*} | \
${.CURDIR:M*/emulators/virtualbox-ose-kmod*} | \
${.CURDIR:M*/deskutils/kdepimlibs4*} | \
${.CURDIR:M*/devel/apache-ant*} | \
${.CURDIR:M*/devel/icu*} | \
${.CURDIR:M*/devel/kdevelop-kde4*} | \
${.CURDIR:M*/devel/kdevplatform*} | \
${.CURDIR:M*/devel/log4j*} | \
${.CURDIR:M*/devel/qt4-corelib*} | \
${.CURDIR:M*/x11-toolkits/qt4-gui*} | \
${.CURDIR:M*/graphics/qt4-svg*} | \
${.CURDIR:M*/x11/qt4-opengl*} | \
${.CURDIR:M*/x11-servers/xorg-server*} | \
${.CURDIR:M*/x11-drivers/xf86-video-vesa*} | \
${.CURDIR:M*/x11-drivers/xf86-video-intel*} | \
${.CURDIR:M*/games/kdegames4*} | \
${.CURDIR:M*/graphics/tonicpoint-viewer*} | \
${.CURDIR:M*/java/* } | \
${.CURDIR:M*/math/fftw3*} | \
${.CURDIR:M*/multimedia/avidemux2*} | \
${.CURDIR:M*/multimedia/kdemultimedia4*} | \
${.CURDIR:M*/multimedia/vlc*} | \
${.CURDIR:M*/multimedia/xbmc*} | \
${.CURDIR:M*/net/kdenetwork4*} | \
${.CURDIR:M*/net/mpich2*} | \
${.CURDIR:M*/net/opal3*} | \
${.CURDIR:M*/net-p2p/ktorrent*} | \
${.CURDIR:M*/net-p2p/vuze*} | \
${.CURDIR:M*/sysutils/lsof*} | \
${.CURDIR:M*/textproc/docbook-xsl*} | \
${.CURDIR:M*/textproc/fop*} | \
${.CURDIR:M*/x11/kde4-baseapps*} | \
${.CURDIR:M*/x11/kde4-workspace*} | \
${.CURDIR:M*/x11/lxpanel*} | \
${.CURDIR:M*/x11-toolkits/swt*} | \
${.CURDIR:M*/graphics/svgalib*} | \
${.CURDIR:M*/multimedia/ffmpeg-011*}
USE_GCC?=4.6+
.endif

.if ${.CURDIR:M*/usr/ports/*}
.if !defined(USE_GCC)
.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == "cpp"
CPP=clang-cpp
.endif
.endif
.endif


# added by use.perl 2013-01-04 12:27:45
PERL_VERSION=5.14.2

I might add that my computer had been crashing more often since using clang, as well as build failures. I am not sure if I am supposed to be using clang or gcc anymore :s
 
The default for 9.X is still gcc. Whether mixing three different compilers is a good idea with ports, I don't know. It should be okay, but I have not tried it. If I were having that problem, I would probably start by removing all the custom settings and rebuilding ports with the defaults.

Your system should not be crashing, although people can mean a variety of things when they say that.
 
wblock@ said:
The default for 9.X is still gcc. Whether mixing three different compilers is a good idea with ports, I don't know. It should be okay, but I have not tried it. If I were having that problem, I would probably start by removing all the custom settings and rebuilding ports with the defaults.
Click to expand...
OK, I will see if that helps. Should I rebuild every port with gcc, or should I just try rebuilding converters/iconv?

wblock@ said:
Your system should not be crashing, although people can mean a variety of things when they say that.
Click to expand...
Well, occasionally my computer would suddenly stop and reboot. I disabled coredump after awhile getting annoyed with having to wait in the boot process for core to process :s maybe not the best idea to do with a computer that does that... It wasn't all that common back then. It is getting more common now, though. I think it might have to do with something in the X related stuff. It had crashed while watching stuff on mplayer or using firefox. In fact, in most cases, I think firefox was running.
 
I tried rebuilding just the four ports, but no luck. I guess I'm off to rebuilding the whole thing again.... thanks for the help :)
 
Hmmm before diving into building everything from scratch, I decided to give portmaster -D -H -f a try on those 4 ports. One of the build failed, and, upon inspecting the log file, I realized the port was being built with clang. Prior to this, I have commented out everything in /etc/make.conf related to compilers, so there's nothing in that file that forces the use of any compiler. Is this normal for the ports to be built with clang by default? The port that failed, which was devel/qt4-corelib as well as few other qt4 related ports, had to be built with the gcc 4.6+ when I last was building ports from scratch, which was done by the use of the /etc/make.conf. What should I do with this?
 
Are you sure your upgrade to 9-STABLE was complete?

I can't think of any likely way that a port would use clang by default, unless maybe it had an option for that. You might be setting environment variables in /root/.cshrc that are forcing the use of clang.
 
An attempt using portmaster -f -D -H failed to work, so I started rebuilding everything, including the world and kernel. It just finished. With some hope, I rebooted the system. No luck. Same error.

I don't have any line in /root/.cshrc regarding any compiler. My /etc/make.conf file has lines regarding texlive, new xorg, and perl, but everything else are commented out with #. Since some ports that previously failed to build in clang were built without a problem this time suggest that clang wasn't forced upon the ports being built; in fact, I saw gcc from port being built as one of the dependencies, so at least some ports if not all were being built with some version of gcc or another.

One of the things I remember doing differently in the previous build of the world, right before problem started happening, was doing make delete-old-lib; could this be the source of the problem? If so, how can I fix it?

EDIT: I just ran virtualbox, and it seems to work as expected, which is definitely different. It at least seems like everything's functional. The dmesg -a shows that I did get the error message regarding libiconv.so.3 and VBoxRT.so. I am not sure what that error message is about, or how I might be able to resolve it.
 
Great! thanks. I was starting to think my computer had a personal vendetta on me haha. Well, at least one problem's being addressed :)
 
You must log in or register to reply here.
Back
Top