VirtualBox

Opened 9 years ago

Closed 9 years ago

#15073 closed defect (fixed)

Building 5.0.14 on FC17 failure: undefined reference to RTLogRelDefaultInstance

Reported by: Timothe Litt Owned by:
Component: other Version: VirtualBox 5.0.14
Keywords: Cc:
Guest type: other Host type: other

Description

I build VirtualBox from source on FC17. Last successful build was 4.3.26.

Upgrading to 5.0.14. Built & installed Qt 4.8.6. Rest of build environment is unchanged. (Yes, I ran configure and sourced env.sh.)

Attempted to build VirtualBox, failed. Clues would be appreciated.

Fails here (full build log attached): 

tstAsmStructs: SUCCESS
kBuild: Linking VBoxSharedClipboard
kBuild: Linking VBoxGuestPropSvc
kBuild: Linking VBoxGuestControlSvc
kBuild: Linking VBoxDragAndDropSvc
kBuild: Linking VBoxHostChannel
kBuild: Installing DbgPlugInDiggers => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/DbgPlugInDiggers.so
kBuild: Linking VBoxXPCOMIPCC
kBuild: Linking VBoxRemPrimary
kBuild: Linking tstVD
kBuild: Linking tstVD-2
kBuild: Linking tstVDCopy
kBuild: Linking tstVDSnap
kBuild: Linking tstVDShareable
kBuild: Linking tstVDIo
kBuild: Linking tstInstrEmul
kBuild: Linking tstVMM
kBuild: Linking tstVMM-HM
kBuild: Linking tstVMMFork
kBuild: Linking tstCFGM
kBuild: Linking tstSSM
kBuild: Linking tstVMREQ
kBuild: Linking tstMMHyperHeap
kBuild: Linking tstAnimate
kBuild: Linking tstMicro
kBuild: Linking tstPDMAsyncCompletion
kBuild: Linking tstPDMAsyncCompletionStress
kBuild: Linking tstUsbMouse
kBuild: Linking tstnsIFileTest
kBuild: Linking tstTestArray
kBuild: Linking tstTestAutoLock
kBuild: Linking tstTestCOMPtr
kBuild: Linking tstTestCOMPtrEq
kBuild: Linking tstTestCRT
kBuild: Linking tstTestFactory
/opt/VirtualBox/VBoxREM.so: undefined reference to `RTLogRelDefaultInstance'
collect2: ld returned 1 exit status
kmk: *** [/home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/obj/tstUsbMouse/tstUsbMouse] Error 1
The failing command:
@g++               '-Wl,-rpath,/opt/VirtualBox' '-Wl,-rpath,/opt/VirtualBox'  -Wl,-z,noexecstack,-z,relro -Wl,--as-needed -m64   -o /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/obj/tstUsbMouse/tstUsbMouse /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/obj/tstUsbMouse/tstUsbMouse.o /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/obj/tstUsbMouse/dt/UsbMouse.o     /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/VBoxVMM.so   /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/VBoxRT.so   -lpthread   -lm   -lrt   -ldl
kmk: *** Waiting for unfinished jobs....

Attachments (3)

vbuild.log​ (119.3 KB ) - added by Timothe Litt 9 years ago.
Build Log
AutoConfig.kmk​ (2.1 KB ) - added by Timothe Litt 9 years ago.
Autoconfig.cmk
env.sh​ (988 bytes ) - added by Timothe Litt 9 years ago.
env.sh

Download all attachments as: .zip

Change History (8)

by Timothe Litt, 9 years ago

Attachment: vbuild.log​ added

Build Log

by Timothe Litt, 9 years ago

Attachment: AutoConfig.kmk​ added

Autoconfig.cmk

by Timothe Litt, 9 years ago

Attachment: env.sh​ added

env.sh

comment:1 by Frank Mehnert, 9 years ago

Resolution: → worksforme
Status: new → closed

Sorry, Fedora 17 is not supported by upstream anymore. We build 5.0.x on EL5, EL6, EL7, Fedora 18, several Ubuntu versions and other distributions and don't see a problem. You might want to go to forums.virtualbox.org to ask for help there.

comment:2 by Timothe Litt, 9 years ago

Resolution: worksforme
Status: closed → reopened

After some digging, I believe that this doesn't have anything to do with FC17. It appears that the source kit has an issue.

As far as I can tell, the symbol RTLogRelDefaultInstance is defined in vboxguest/common/log/logrel.c.

In 5.x, it looks like the name was changed to RTLogRelGetDefaultInstance (Get was added)

It appears that the tests, which are built by default in the source kit, still use the old name.

So attempts to link the tests fail. Either the tests weren't updated, or the source kit has the old tests.

I hacked Config.kmk by setting 

VBOX_WITH_VALIDATIONKIT =
VBOX_WITH_TESTCASES =

where they're set to 1.

And the build succeeds. I'm happy not building the validation suite.

I didn't track down which of the following contribute to the issue, but someone should: 

 find VirtualBox-5.0.14 -name '*.c' -o -name '*.cpp' -exec grep -H RTLogDefaultInstance {} \;
VirtualBox-5.0.14/src/recompiler/VBoxREMWrapper.cpp:    { "RTLogDefaultInstance",                   (void *)(uintptr_t)&RTLogDefaultInstance,           NULL,                                       0,                                                     REMFNDESC_FLAGS_RET_INT,    sizeof(PRTLOGGER),  NULL },
VirtualBox-5.0.14/src/recompiler/VBoxREMWrapper.cpp:    { "RTLogDefaultInstanceEx",                 (void *)(uintptr_t)&RTLogDefaultInstance,           &g_aArgsRTLogGetDefaultInstanceEx[0],       RT_ELEMENTS(g_aArgsRTLogGetDefaultInstanceEx),         REMFNDESC_FLAGS_RET_INT,    sizeof(PRTLOGGER),  NULL },
VirtualBox-5.0.14/src/VBox/Additions/common/VBoxGuestLib/VBoxGuestR3LibRuntimeXF86.cpp:RTDECL(PRTLOGGER) RTLogDefaultInstanceEx(uint32_t fFlagsAndGroup)
VirtualBox-5.0.14/src/VBox/Main/src-client/MachineDebuggerImpl.cpp:    const PRTLOGGER pLogInstance = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/HostDrivers/Support/SUPLib.cpp:        { "RTLogDefaultInstance",                   0xefef003b },
VirtualBox-5.0.14/src/VBox/HostDrivers/Support/SUPDrv.cpp:    { "RTLogDefaultInstance",                   (void *)RTLogDefaultInstance },
VirtualBox-5.0.14/src/VBox/HostDrivers/Support/SUPDrv.cpp:    { "RTLogDefaultInstanceEx",                 (void *)RTLogDefaultInstanceEx },
VirtualBox-5.0.14/src/VBox/VMM/VMMR0/VMMR0.cpp:        LogCom(("vmmR0InitVM: before %p\n", RTLogDefaultInstance()));
VirtualBox-5.0.14/src/VBox/VMM/VMMR0/VMMR0.cpp:        LogCom(("vmmR0InitVM: after %p reg\n", RTLogDefaultInstance()));
VirtualBox-5.0.14/src/VBox/VMM/VMMR0/VMMR0.cpp:        LogCom(("vmmR0InitVM: after %p dereg\n", RTLogDefaultInstance()));
VirtualBox-5.0.14/src/VBox/VMM/VMMR0/VMMR0.cpp:        LogCom(("vmmR0InitVM: after %p reg2\n", RTLogDefaultInstance()));
VirtualBox-5.0.14/src/VBox/VMM/VMMR0/VMMR0.cpp:        LogCom(("vmmR0InitVM: after %p dereg2\n", RTLogDefaultInstance()));
VirtualBox-5.0.14/src/VBox/VMM/VMMR3/DBGFLog.cpp:        pLogger = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/VMM/VMMR3/VMM.cpp:    PRTLOGGER pLogger = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/VMM/VMMR3/VMM.cpp:    PRTLOGGER const pDefault = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/VMM/VMMR3/VMMGuruMeditation.cpp:    pHlp->pLogger     = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/VMM/VMMR3/VMMGuruMeditation.cpp:        pHlp->pLogger = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/Runtime/testcase/tstLdr-4.cpp:    else if (!strcmp(pszSymbol, "RTLogDefaultInstance") || !strcmp(pszSymbol, "_RTLogDefaultInstance"))
VirtualBox-5.0.14/src/VBox/Runtime/testcase/tstLdr-4.cpp:        *pValue = (uintptr_t)RTLogDefaultInstance;
VirtualBox-5.0.14/src/VBox/Runtime/testcase/tstPrfRT.cpp:     * RTLogDefaultInstance()
VirtualBox-5.0.14/src/VBox/Runtime/testcase/tstPrfRT.cpp:    ITERATE(RT_NOTHING, RTLogDefaultInstance();, RT_NOTHING, 1000000);
VirtualBox-5.0.14/src/VBox/Runtime/testcase/tstPrfRT.cpp:    PrintResult(u64TotalTS, u64MaxTS, u64MinTS, i, "RTLogDefaultInstance");
VirtualBox-5.0.14/src/VBox/Runtime/VBox/logbackdoor-redirect.cpp:RTDECL(PRTLOGGER) RTLogDefaultInstance(void)
VirtualBox-5.0.14/src/VBox/Runtime/VBox/logbackdoor-redirect.cpp:RTDECL(PRTLOGGER) RTLogDefaultInstanceEx(uint32_t fFlagsAndGroup)
VirtualBox-5.0.14/src/VBox/Runtime/common/misc/assert.cpp:            pLog = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/Runtime/common/misc/assert.cpp:        pLog = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp:        pLogger = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp:        pLogger = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp:        pSrcLogger = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp:        pLogger = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp:        pDstLogger = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp:        pLogger = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp:        pLogger = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp:        pLogger = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp:        pLogger = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp:        pLogger = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp:        pLogger = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp:        pLogger = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp:        pLogger = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp:        pLogger = RTLogDefaultInstance();
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp: * Common worker for RTLogDefaultInstance and RTLogDefaultInstanceEx.
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp:RTDECL(PRTLOGGER)   RTLogDefaultInstance(void)
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp:RT_EXPORT_SYMBOL(RTLogDefaultInstance);
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp:RTDECL(PRTLOGGER)   RTLogDefaultInstanceEx(uint32_t fFlagsAndGroup)
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp:RT_EXPORT_SYMBOL(RTLogDefaultInstanceEx);
VirtualBox-5.0.14/src/VBox/Runtime/common/log/log.cpp:        pLogger = RTLogDefaultInstance();

comment:3 by Frank Mehnert, 9 years ago

The build process you describes complains about RTLogRelDefaultInstance. The complete 5.0.14 tree does not have any occurrence of this symbol. Also, the build error is about /opt/VirtualBox/VBoxREM.so.

I guess the following happens: You have a different version of VirtualBox installed in /opt/VirtualBox. The linker command line includes only explicit references to VBoxVMM.so and VBoxRT.so. As VBoxREM.so is required by VBoxVMM.so but there is no explicit command line for VBoxREM.so specified, the installed version from /opt/VirtualBox is used.

Can you compile the complete tree with the following diff? 

--- src/VBox/Devices/Input/testcase/Makefile.kmk        (revision 105220)
+++ src/VBox/Devices/Input/testcase/Makefile.kmk        (working copy)
@@ -15,7 +15,7 @@
 # hope that it will be useful, but WITHOUT ANY WARRANTY of any kind.
 #
 
-SUB_DEPTH = ../../../..
+SUB_DEPTH = ../../../../..
 include $(KBUILD_PATH)/subheader.kmk
 
 if defined(VBOX_WITH_TESTCASES) && !defined(VBOX_ONLY_ADDITIONS) && !defined(VBOX_ONLY_SDK)
@@ -25,7 +25,7 @@
 tstUsbMouse_DEFS     = VBOX_WITH_VUSB
 tstUsbMouse_INCS     = \
         ../../build
-tstUsbMouse_LIBS     = $(LIB_VMM)
+tstUsbMouse_LIBS     = $(LIB_VMM) $(LIB_REM)
 tstUsbMouse_SOURCES  = \
         tstUsbMouse.cpp \
         ../UsbMouse.cpp

comment:4 by Timothe Litt, 9 years ago

Oops, seems I mistyped the grep. That sent me down the wrong path. Sorry about that.

The behavior has changed since I successfully built & installed 5.0.14.

When I started, /opt/VirtualBox was the installed 4.3.26 (That is, the result of running out/linux.amd64/release/bin/VirtualBox-${VERSION}_OSE-r${REV}.run from that build.) So yes, there would have been a VBoxREM.so there during the build attempt of 5.0.14.

I always build in a subdirectory of a home directory.

I now have 5.0.14 in /opt/VirtualBox, as turning off tests allowed me to complete the build. That's now running, so I can't go back to confirm your theory. But here's what I have done:

Both builds used the files from (copy/pasted from the script I use): 

export MAJORVERSION=5.0
export VERSION=${MAJORVERSION}.14
wget http://download.virtualbox.org/virtualbox/$VERSION/VirtualBox-$VERSION.tar.bz2

Since I've unzipped the bz2 file, I can't sha1sum it now. The sha1 of the extracted .tar is 0f502616de448bbf753bd0a17ccf82c2b3732bf1

To see if the successful build/install changed things, I expanded that tar file into an fresh directory and built without your patch.

We die later than before - but it's a different failure. There seem to be two things going on. I've tried to untangle them.

This is plain configure, no patch, NEW VirtualBox in /opt/VirtualBox: 

kBuild: Linking tstPDMAsyncCompletion
kBuild: Linking tstPDMAsyncCompletionStress
kBuild: Linking tstUsbMouse
kBuild: Linking tstnsIFileTest
kBuild: Linking tstTestArray
kBuild: Linking tstTestAutoLock
kBuild: Linking tstTestCOMPtr
kBuild: Linking tstTestCOMPtrEq
kBuild: Linking tstTestCRT
kBuild: Linking tstTestFactory
kBuild: Linking tstTestHashtables
kBuild: Linking tstTestID
kBuild: Linking tstTestObserverService
kBuild: Linking tstTestPipes
kBuild: Linking tstTestThreads
kBuild: Linking tstTestXPIDLString
kBuild: Linking tstTestDeque
kBuild: Linking tstTestAutoPtr
kBuild: Linking tstTestMinStringAPI
kBuild: Linking tstTestStrings

[Snip...]

kBuild: Linking tstMediumLock
kBuild: Linking tstGuid
kBuild: Linking VBoxSVC
kBuild: Installing tstInstrEmul => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/tstInstrEmul
kBuild: Installing tstVMM => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/tstVMM
kBuild: Installing tstVMM-HM => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/tstVMM-HM
kBuild: Installing tstVMMFork => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/tstVMMFork
kBuild: Installing tstCFGM => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/testcase/tstCFGM
kBuild: Installing tstSSM => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/testcase/tstSSM
kBuild: Installing tstVMREQ => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/tstVMREQ
kBuild: Installing tstMMHyperHeap => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/testcase/tstMMHyperHeap
kBuild: Installing tstAnimate => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/tstAnimate
kBuild: Installing tstMicro => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/tstMicro
kBuild: Installing tstPDMAsyncCompletion => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/tstPDMAsyncCompletion
kBuild: Installing tstPDMAsyncCompletionStress => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/tstPDMAsyncCompletionStress
kBuild: Installing tstUsbMouse => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/testcase/tstUsbMouse
kBuild: Linking VBoxTestOGL
kBuild: Linking VBoxManage
kBuild: Linking VBoxBalloonCtrl
kBuild: Linking VBoxAutostart
kBuild: Linking tstHeadless
kBuild: Linking tstSSLCertDownloads
kBuild: Installing tstnsIFileTest => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/testcase/tstnsIFileTest

[Snip ... ]

Build: Installing tstHeadless => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/testcase/tstHeadless
kBuild: Installing tstSSLCertDownloads => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/tstSSLCertDownloads
kBuild: Installing tstUSBProxyLinux => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/testcase/tstUSBProxyLinux
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
 %&-line parsing enabled.
kBuild: Installing VBoxSharedCrOpenGL => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/VBoxSharedCrOpenGL.so
entering extended mode
kBuild: Installing VBoxSVC => /home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/bin/VBoxSVC
kmk: *** [/home/litt/kits/VirtualBox-5.0.14/out/linux.amd64/release/obj/manual/en_US/UserManual.pdf] Error 1
kmk: *** Waiting for unfinished jobs....
kmk: *** Exiting with status 2

Having the new version in /opt/VirtualBox seems to have an effect.

I don't need the documents, and in the course of previous debugging disabled them.

So, I started over from the .tar file, no patch, no docs, still new /opt 

# WATCOM=/usr/local/watcom ./configure --disable-docs

This completes.

I have also built with the patch applied, and that completes with docs disabled.

But as I can't try the obvious (old VirtualBox in /opt, docs disabled), we don't know if the patch cures the original symptom. It doesn't seem to do any harm.

Turning off the doc build can't have anything to do with the original undefined symbol, so we have to assume that was cured by installing the new build. (After being bypassed by building without tests.)

Thanks for trying to figure this out.

comment:5 by Frank Mehnert, 9 years ago

Resolution: → fixed
Status: reopened → closed

The diff I posted would indeed solve your above problem as long as you have VBox 4.3.x installed in /opt/VirtualBox. There is one additional diff required: 

--- src/VBox/Debugger/Makefile.kmk      (revision 105224)
+++ src/VBox/Debugger/Makefile.kmk      (revision 105225)
@@ -123,6 +123,7 @@
 tstVBoxDbg_SOURCES      = testcase/tstVBoxDbg.cpp
 tstVBoxDbg_LIBS         = \
        $(LIB_VMM) \
+       $(LIB_REM) \
        $(LIB_RUNTIME)
   ifeq ($(KBUILD_TARGET),win)
 tstVBoxDbg_LIBS        += \

Both fixes will be included in the next 5.0.x maintenance release.

The docs build error should be visible in out/linux.amd64/release/obj/manual/en_US/UserManual.log. I guess some TeX font package is missing.

Note: See TracTickets for help on using tickets.

© 2025 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy Automated Access Etiquette