FreeBSD 7RC2 and VMware tools

[Dimitri Yioulos]

On Mon, 18 Feb 2008 15:58:26 -0500, John Nielsen wrote
> On Monday 18 February 2008 01:47:14 pm Dimitri Yioulos wrote:
> > On Mon, 18 Feb 2008 13:29:28 -0500, John Nielsen wrote
> >
> > > On Monday 18 February 2008 12:31:37 pm Dimitri Yioulos wrote:
> > > > On Sun, 17 Feb 2008 22:44:17 -0500, John Nielsen wrote
> > > >
> > > > > On Sunday 17 February 2008 01:06:28 pm Dimitri Yioulos wrote:
> > > > > > I'm not sure whether to have posted this here or on a VMware
> > > > > > list; apologies if I'm in the wrong place.
> > > > > >
> > > > > > The other day, I did a fresh install of v. 7RC2 from the
> > > > > > minimal CD on a CentOS 5.1 box running VMware server 1.0.4.  I
> > > > > > had previously successfully installed v. 6.2, and upgraded to
> > > > > > 6.3 on the same box. All has gone well, except for the
> > > > > > installation of VMware Tools. Getting the Tools tarball and
> > > > > > extracting the requisite files was trivial. However, when I try
> > > > > > to run Vmware-Config-Tools.pl, I get a message saying that the
> > > > > > program must be run on a virtual machine. Well, it is.  Is
> > > > > > there a needed FBSD package I'm missing (the Tools install
> > > > > > program doesn't complain about it).  A known issue, or bug,
> > > > > > maybe?  Or is VMware support not yet enabled?  Help would be
> > > > > > greatly appreciated.
> > > > >
> > > > > I just went through almost the same thing, installing FreeBSD 7
> > > > > under VMware Workstation on Windows. The config-tools script has
> > > > > a hard-coded version check which looks for libc.so.6 under /lib
> > > > > only. Rather than mess with the script, I just hard-linked the
> > > > > library from /usr/local/lib/compat (where it was installed by the
> > > > > compat6x port). Seemed to work fine after that. You'll need to be
> > > > > careful not to erase it if you ever run "make delete-old-libs",
> > > > > though.
> > > >
> > > > Thanks for the response!
> > > >
> > > > A symlink won't do for the above?
> > >
> > > Try it and see! I think I decided on a hard link since the script
> > > uses something like "if [ -f /lib/libc.so.6 ]" so it's looking only
> > > for a regular file and not a symlink.
> >
> > Hmm, when I try to hard-link ("ln /usr/compat/linux/lib/libc.so.6
> > libc.so.6"), I get "ln: ./libc.so.6: Cross-device link".  But, when I
> > do a symlink, which takes, I get "/usr/libexec/ld-elf.so.1: Shared
> > object "ld-linux.so.2" not found, required by "libc.so.6"" when i run
> > vmware-config-tools.pl.  So, I symlink ld-linux.so.2, and run tools. 
> > Then, I get "/usr/libexec/ld-elf.so.1: Undefined symbol "__stdoutp"
> > referenced from COPY relocation in /usr/local/sbin/vmware-checkvm". 
> > Arrgh.  Any other ideas?
> 
> You have /usr on a different partition than / in your VM, so you can't do 
> a hard link. I would just copy the file back to /lib and not worry about 
> it. Linking in other random libraries will cause problems, as you've 
> observed.
> 
> JN


If I copy libc.so.6 to /lib, then tools complains about ld-linux.so.2.  If I copy
ld-linux.so.2, it then complains about "/usr/libexec/ld-elf.so.1: Undefined symbol
"__stdoutp" referenced from COPY relocation in /usr/local/sbin/vmware-checkvm".  This is
pretty much the same as if I symlink the two files.  Even though I'm a "glass half-full"
guy, this is beginning to look dire (but it's the worst thing to happen to me, I'm sure
I'll live).  Still, it would be nice to get this working.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.