[vbox-dev] Svn Commit 48852 breaks build an Fedora17.x64 and Fedora18.x64

[Peter Gsellmann]

Hi Frank!

Am 2013-10-09 20:59, schrieb Frank Mehnert:
> Hi Peter,
> 
> On Wednesday 09 October 2013 20:03:09 Peter Gsellmann wrote:
>> Am 2013-10-09 11:33, schrieb Frank Mehnert:
>>> On Tuesday 08 October 2013 13:39:20 Peter Gsellmann wrote:
>>>> error messages are:
>>>> undefined reference to `dlopen' ( and other functions of libdl )
>>>> /home/peter/VirtualBox/vbox/src/VBox/Runtime/r3/xml.cpp:402: undefined
>>>> reference to `xmlSetExternalEntityLoader' ( and other functions of
>>>> libxml2 )
>>>>
>>>> [...]
>>>>
>>>> How can i fetch the SVN version corresponding do Release 4.2.18_88780 ?
>>>> Obviously not by  svn update -r88780
>>>> Also not by  svn switch http://www.virtualbox.org/svn/vbox/tags/88780
>>>> Also  svn log | grep 88780  doesnt reveal.
>>>> Is there a public document of the relation of the Build-number to
>>>> SVN-number ?
>>>
>>> We don't publish the SVN repository for the branch releases, too much
>>
>> Not even a small text file with the last build number in root-directory?
> 
> as the name says: branch builds are done from a branch, not from trunk.
> The public subversion repository is a mirror of our internal trunk.
> 
>>> maintenance effort, sorry. Just use the tarball which is part of every
>>> release.
>>
>> This means, eventually the release tarball is patched and eventually not
>> existent in the SVN repository?
> 
> As I said, release tarballs are taken from branches. But yes, there is often
> no direct relationship between the public repository and a branch release.
> 
>> So another question: if my intention is to deliver a patch upstream is
>> it better to base it on SVN or on tarball?
>> ( svn diff is a much simpler way to produce a patch )
> 
> It makes more sense to create a patch against the public SVN.
So i have to get the SVN version compiling and running.


> Regarding your problem: I've just tried to build vbox-img from the public
> repository and I was successful. Do you see line 118 in
> 
>   src/VBox/Storage/testcase/Makefile.kmk
> 
>   ifdef SDK_VBOX_LIBXML2_LIBS
>    vbox-img_LIBS += xml2 lzma
>   endif
exactly the same


> SDK_VBOX_LIBXML2_LIBS should be defined by your AutoConfig.kmk (generated by
> the configure script). I don't see these two libraries in your command line
> and I wonder why ...
AutoConfig.kmk:
SDK_VBOX_LIBXML2_INCS          := /usr/include/libxml2
SDK_VBOX_LIBXML2_LIBS          := xml2


Todays build with SVN49014 :

failing command (with output):
g++ '-Wl,-rpath,$(VBOX_ORIGIN)' -static  -Wl,-z,noexecstack
-Wl,--as-needed -Wl,-z,origin -m64 -o
/home/peter/VirtualBox/vbox/out/linux.amd64/release/obj/vbox-img/vbox-img /home/peter/VirtualBox/vbox/out/linux.amd64/release/obj/vbox-img/vbox-img.o
/home/peter/VirtualBox/vbox/out/linux.amd64/release/obj/vbox-img/dt/VD.o
/home/peter/VirtualBox/vbox/out/linux.amd64/release/obj/vbox-img/dt/VDVfs.o
/home/peter/VirtualBox/vbox/out/linux.amd64/release/obj/vbox-img/dt/VDI.o /home/peter/VirtualBox/vbox/out/linux.amd64/release/obj/vbox-img/dt/VMDK.o
/home/peter/VirtualBox/vbox/out/linux.amd64/release/obj/vbox-img/dt/VHD.o /home/peter/VirtualBox/vbox/out/linux.amd64/release/obj/vbox-img/dt/DMG.o
/home/peter/VirtualBox/vbox/out/linux.amd64/release/obj/vbox-img/dt/Parallels.o
/home/peter/VirtualBox/vbox/out/linux.amd64/release/obj/vbox-img/dt/ISCSI.o
/home/peter/VirtualBox/vbox/out/linux.amd64/release/obj/vbox-img/dt/RAW.o /home/peter/VirtualBox/vbox/out/linux.amd64/release/obj/vbox-img/dt/QED.o
/home/peter/VirtualBox/vbox/out/linux.amd64/release/obj/vbox-img/dt/QCOW.o
/home/peter/VirtualBox/vbox/out/linux.amd64/release/obj/vbox-img/dt/VHDX.o
/home/peter/VirtualBox/vbox/out/linux.amd64/release/obj/vbox-img/dt/VCICache.o
/home/peter/VirtualBox/vbox/out/linux.amd64/release/obj/vbox-img/dt/VDIfVfs.o
    /home/peter/VirtualBox/vbox/out/linux.amd64/release/lib/RuntimeR3.a
  /home/peter/VirtualBox/vbox/out/linux.amd64/release/lib/VBox-liblzf.a
  -lz   -lcrypt   -lxml2   -llzma
/home/peter/VirtualBox/vbox/out/linux.amd64/release/lib/RuntimeR3.a
/home/peter/VirtualBox/vbox/out/linux.amd64/release/lib/VBox-liblzf.a
-lz   -lcrypt   -lpthread   -lm   -lrt   -ldl   -lssl   -lcrypto
/usr/bin/ld: cannot find -llzma
/home/peter/VirtualBox/vbox/out/linux.amd64/release/lib/RuntimeR3.a(fs3-posix.o):
In function `rtFsObjInfoAttrSetUnixGroup':
/home/peter/VirtualBox/vbox/src/VBox/Runtime/r3/posix/fs3-posix.cpp:80:
warning: Using 'getgrgid_r' in statically linked applications requires
at runtime the shared libraries from the glibc version used for linking
/home/peter/VirtualBox/vbox/out/linux.amd64/release/lib/RuntimeR3.a(fs3-posix.o):
In function `rtFsObjInfoAttrSetUnixOwner':
/home/peter/VirtualBox/vbox/src/VBox/Runtime/r3/posix/fs3-posix.cpp:58:
warning: Using 'getpwuid_r' in statically linked applications requires
at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/libxml2.a(nanohttp.o):
In function `xmlNanoHTTPConnectHost':
(.text+0x61e): warning: Using 'getaddrinfo' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/libpthread.a(libpthread.o):
In function `sem_open':
(.text+0x67f8): warning: the use of `mktemp' is dangerous, better use
`mkstemp'
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/libxml2.a(nanohttp.o):
In function `xmlNanoHTTPConnectHost':
(.text+0x6d4): warning: Using 'gethostbyname' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
collect2: Fehler: ld gab 1 als Ende-Status zurü



liblzma is missing!

I have installed package  xz-libs,xz-devel  which contains  liblzma.so.5
but no  liblzma.a
>From which package is the  liblzma.a  on your build machine?
Here,  yum provides /usr/lib64/liblzma.a  finds nothing.





Grüße,
Peter