Unresolved symbols building 4.1.2/4.0.12 on 64-bit OSX Lion

Discussions related to using the OSE version of VirtualBox.

Unresolved symbols building 4.1.2/4.0.12 on 64-bit OSX Lion

Postby arend » 11. Sep 2011, 23:32

Hi,

After building VirtualBox 4.0.12 OSE on Snow Leopard (32-bit) with xCode 3.2.3 I am trying to build a 64-bit version of VirtualBox OSE for OSX. As my Macbook and my Mac Mini cannot boot into a 64-bit kernel for Snow Leopard (this is a known limitation for this hardware) I upgraded the Mini to Lion where booting to the 64-bit kernel is the default. After changing 'configure' to recognize my version of Lion

Code: Select all   Expand viewCollapse view
  case "$darwin_ver" in
    11\.*)
      darwin_ver="10.6"
      if [ "$BUILD_MACHINE" = "x86" ]; then


configuring with

Code: Select all   Expand viewCollapse view
./configure --with-openssl-dir=/opt/local --disable-python --disable-java --disable-docs --target-arch=amd64


and adding this LocalConfig.kmk

Code: Select all   Expand viewCollapse view
VBOX_DEF_MACOSX_VERSION_MIN = 10.6
VBOX_DARWIN_NO_COMPACT_LINKEDIT =
VBOX_MACOS_10_5_WORKAROUND =


I tried to build OSE 4.1.2 as well as OSE 4.0.12 with xCode 4.1.1 as well as 3.2.3 (not officially supported on Lion) and in all cases get the same build errror message:

Code: Select all   Expand viewCollapse view
kBuild: Linking vbox-img
Undefined symbols:
  "_libiconv", referenced from:
      rtStrConvertUncached(void const*, unsigned long, char const*, void**, unsigned long, char const*, unsigned int)in RuntimeR3.a(utf8-posix.o)
      rtstrConvertCached(void const*, unsigned long, char const*, void**, unsigned long, char const*, unsigned int, void**)in RuntimeR3.a(utf8-posix.o)
  "_libiconv_close", referenced from:
      rtStrConvertUncached(void const*, unsigned long, char const*, void**, unsigned long, char const*, unsigned int)in RuntimeR3.a(utf8-posix.o)
      rtStrConvertUncached(void const*, unsigned long, char const*, void**, unsigned long, char const*, unsigned int)in RuntimeR3.a(utf8-posix.o)
      rtstrConvertCached(void const*, unsigned long, char const*, void**, unsigned long, char const*, unsigned int, void**)in RuntimeR3.a(utf8-posix.o)
      _rtStrIconvCacheDestroy in RuntimeR3.a(utf8-posix.o)
  "_libiconv_open", referenced from:
      rtStrConvertUncached(void const*, unsigned long, char const*, void**, unsigned long, char const*, unsigned int)in RuntimeR3.a(utf8-posix.o)
      rtstrConvertCached(void const*, unsigned long, char const*, void**, unsigned long, char const*, unsigned int, void**)in RuntimeR3.a(utf8-posix.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
kmk: *** [/Users/adittmer/VBOX_4.X/VirtualBox-4.0.12_OSE/out/darwin.amd64/release/obj/vbox-img/vbox-img] Error 1
The failing command:
@g++-4.2                 -mmacosx-version-min=10.6 -Wl,-syslibroot,/Developer/SDKs/MacOSX10.6.sdk -Wl,-headerpad_max_install_names   -m64   -o /Users/adittmer/VBOX_4.X/VirtualBox-4.0.12_OSE/out/darwin.amd64/release/obj/vbox-img/vbox-img -filelist /Users/adittmer/VBOX_4.X/VirtualBox-4.0.12_OSE/out/darwin.amd64/release/obj/vbox-img/vbox-img.rsp    /Users/adittmer/VBOX_4.X/VirtualBox-4.0.12_OSE/out/darwin.amd64/release/lib/RuntimeR3.a   /Users/adittmer/VBOX_4.X/VirtualBox-4.0.12_OSE/out/darwin.amd64/release/lib/VBox-liblzf.a   -lz   -liconv
kmk: *** [/Users/adittmer/VBOX_4.X/VirtualBox-4.0.12_OSE/out/darwin.amd64/release/obj/vbox-img/vbox-img] Deleting file `/Users/adittmer/VBOX_4.X/VirtualBox-4.0.12_OSE/out/darwin.amd64/release/obj/vbox-img/vbox-img.rsp'


Looking at the symbol tables this makes sense

Code: Select all   Expand viewCollapse view
SanRafael:lib adittmer$ nm -a -arch x86_64 /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libiconv.dylib | grep libiconv
00000000000fa760 D __libiconv_version
00000000000159a4 T _libiconv_relocate
000000000001599a T _libiconv_set_relocation_prefix


where for the 32-bit architecture the output shows

Code: Select all   Expand viewCollapse view
SanRafael:lib adittmer$ nm -a -arch i386 /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libiconv.dylib | grep libiconv
000f5be0 D __libiconv_version
000086af T _libiconv
0000fd7a T _libiconv_close
000158d8 T _libiconv_open
00015dae T _libiconv_relocate
00015d9f T _libiconv_set_relocation_prefix
00008bd9 T _libiconvctl
00008847 T _libiconvlist


Forcing the linker to link with /opt/local/lib/libiconv.dylib satisfies the dependencies but I am not sure how to configure the build process accordingly and whether it is even the right thing to do.

Thank you in advance for your help.
arend
 
Posts: 60
Joined: 14. Mar 2010, 21:56
Primary OS: MS Windows XP
VBox Version: OSE self-compiled
Guest OSses: Windows XP

Re: Unresolved symbols building 4.1.2/4.0.12 on 64-bit OSX L

Postby Perryg » 11. Sep 2011, 23:56

I think that the issue is because of Lion arend. Not totally sure but I see a lot if comments about items being held back in the source because it does not work in Lion yet. Probably causing your unresolved symbols. Of course you would need to ask the DEVs to be sure.

I do have a question though. Isn't Lion version 10.7?
Perryg
Site Moderator
 
Posts: 34373
Joined: 6. Sep 2008, 22:55
Primary OS: Linux other
VBox Version: OSE self-compiled
Guest OSses: *NIX

Re: Unresolved symbols building 4.1.2/4.0.12 on 64-bit OSX L

Postby arend » 12. Sep 2011, 02:32

Perry, thank you for your reply. I was thinking that I probably don't have to build everything as the 32-bit binaries should work on a 64-bit system as well. I can probably find out from the working production build which binaries are 64-bit specific (like the kernel drivers) and then only build those. Do you know of any flags to limit the build to just the kernel drivers?

Regarding the versioning ... it did not make sense to me either but I think I just figured it out ... configure goes by 'uname -r' which shows the kernel version which is different from the OS version. On my Lion system the kernel version is 11.0.0 on my Snow Leopard the kernel version is 10.4.1 (This may not be intended for configure and maybe it is a bug). You can see both versions if you go to 'About this Mac | More Info | Software'
arend
 
Posts: 60
Joined: 14. Mar 2010, 21:56
Primary OS: MS Windows XP
VBox Version: OSE self-compiled
Guest OSses: Windows XP

Re: Unresolved symbols building 4.1.2/4.0.12 on 64-bit OSX L

Postby Perryg » 12. Sep 2011, 14:08

Here's a list of all the config switches I know of. viewtopic.php?f=31&t=38114
The kmods is what builds the kernel modules. Not sure what else is really needed to be able to build them but I guess you can use all the disable switches except kmods and see. Wish I knew more to tell you but as you know the code is all over the place and even though it is documented better than any I have see, it is still hard to find what you need sometimes.
Perryg
Site Moderator
 
Posts: 34373
Joined: 6. Sep 2008, 22:55
Primary OS: Linux other
VBox Version: OSE self-compiled
Guest OSses: *NIX

Re: Unresolved symbols building 4.1.2/4.0.12 on 64-bit OSX L

Postby arend » 13. Sep 2011, 20:58

Problem solved thanks to the helpful folks on the developer mailing list (Martin Simmons, Francois Revol, K M Darshan) :D

Issue was the configure flag --with-openssl=/opt/local. It works without this flag. As I am not sure how to see the actual build command line I removed a semicolon at the end of a line in utf8-posix.cpp to induce a build error and have a look at the compiler command line.

With the --with-openssl=/opt/local in configure the line for the build line of utf8-posix.cpp contains '-I/opt/local/include'. So it pulls in the header for libiconv in /opt/local/lib. At link time the linker links libiconv.dylib from /Developer/SDKs/MacOSX10.6.sdk that does not match the header from /opt/local/include

The very same problem was reported a while back and the suggested workaround by Kentaro Kawamoto who reported the issue was to add /opt/local/lib as a lib path for the linker:

http://comments.gmane.org/gmane.comp.emulators.virtualbox.devel/2862

I am not sure if this should be considered a bug but I feel that a flag for specifying the openssl location should not impact the build of a component that does not use openssl at all.
arend
 
Posts: 60
Joined: 14. Mar 2010, 21:56
Primary OS: MS Windows XP
VBox Version: OSE self-compiled
Guest OSses: Windows XP

Re: Unresolved symbols building 4.1.2/4.0.12 on 64-bit OSX L

Postby Perryg » 13. Sep 2011, 21:27

Welcome to my world. Congrats of finding the issue.
I was watching (lurking) the convo while it happened.
Perryg
Site Moderator
 
Posts: 34373
Joined: 6. Sep 2008, 22:55
Primary OS: Linux other
VBox Version: OSE self-compiled
Guest OSses: *NIX

Re: Unresolved symbols building 4.1.2/4.0.12 on 64-bit OSX L

Postby Perryg » 13. Sep 2011, 21:36

Tell you what.
If you want to create this as a turorial I will place it in the OSE tutorials where you can edit it if needed.
Just let me know when you are finished and that you do want it included and I will make it happen.
Perryg
Site Moderator
 
Posts: 34373
Joined: 6. Sep 2008, 22:55
Primary OS: Linux other
VBox Version: OSE self-compiled
Guest OSses: *NIX

Re: Unresolved symbols building 4.1.2/4.0.12 on 64-bit OSX L

Postby arend » 13. Sep 2011, 22:09

Thank you. This was really weighing on me ... I have to build as I want to incorporate my own workaround for this bug http://www.virtualbox.org/ticket/9549 into the most stable current version which is 4.0.12.

Yes. I can create a quick write-up on this issue that people can use in conjunction with the official build instructions. I will send it as a PM when I am done.
arend
 
Posts: 60
Joined: 14. Mar 2010, 21:56
Primary OS: MS Windows XP
VBox Version: OSE self-compiled
Guest OSses: Windows XP

Re: Unresolved symbols building 4.1.2/4.0.12 on 64-bit OSX L

Postby Perryg » 13. Sep 2011, 22:22

If you just post it here I will move it and that way you will get the credit for it.
Perryg
Site Moderator
 
Posts: 34373
Joined: 6. Sep 2008, 22:55
Primary OS: Linux other
VBox Version: OSE self-compiled
Guest OSses: *NIX


Return to VirtualBox OSE

Who is online

Users browsing this forum: No registered users and 1 guest