Tiny Core 9.0 Alpha 1 Testing

[andyj]

Would it be possible for the next alpha build to not to strip glibc? I'm trying to figure out why open-vm-tools builds on 8.2 with glibc 2.24 and not on 9.0 with glibc 2.26. Somewhere along the way libtool says it can't find the xdr* functions that are supposed to be in glibc. I compiled glibc myself but when I grafted it into the rootfs somebody (busybox?) complained about not being able to find libcrypt.

[Juanito]

You can compile glibc, install it somewhere outside of the root filesystem, and make a tarball of it.

Next, boot tc, copy the tarball to / and untar it as root.

[andyj]

I tried that first, but it didn't work like I hoped. How can I get it to boot with the un-stripped libraries?

[Juanito]

Hmm - it works for me...

To boot with unstripped libs you’d need to replace the libs in roots64.gz

[andyj]

I did that. That's how I got the "cant find libcrypt" error. I wouldn't have thought there was another step, but maybe there is something else that needs to be done to the rootfs before putting it back together? I've added plenty of stuff to the rootfs over the years so I am familiar with that process, but I've never swapped out core libraries before.

[andyj]

OK, I had to ldconfig in the new fs first. But now it can't login, complaining it can't set groups. There's another step?

[andyj]

Got it to work, didn't fix the problem making open-vm-tools, so maybe it's a difference in gcc 7.2 behavior. Anyway, I discovered that /lib/udev owner is 755 instead of root. Also, would it be possible to have ldd to give a version string when asked by adding this as the first option:

Code: [Select]

  --version) echo 'ldd (GNU libc) 2.26'
    break
    ;;

This would make a few glibc version detection tricks in configure happier.

[Juanito]

Maybe it would be better to take the version from /lib/libc.so.6 so that the ldd script would not need to be changed every glibc update?

Code: [Select]

$ /lib/libc.so.6
GNU C Library (GNU libc) stable release version 2.26, by Roland McGrath et al.
...

[Juanito]

Got it to work, didn't fix the problem making open-vm-tools, so maybe it's a difference in gcc 7.2 behavior.

rpc has been obsolete in glibc for a while now - using open-vm-tools-stable-10.2.0 with:

Code: [Select]

LIBS="-ltirpc" CC="gcc -flto -fuse-linker-plugin -mtune=generic -Os -pipe" CXX="g++-flto -fuse-linker-plugin -mtune=generic -Os -pipe" ./configure --prefix=/usr/local --disable-static --localstatedir=/var --sysconfdir=/etc --without-kernel-modules --disable-glibc-check --without-pam --without-xerces --without-dnet
..seems to work?

Edit:

Code: [Select]

$ nm -D /lib/libnsl-2.26.so | grep -i xdrmem_create
                 U xdrmem_create
$ nm -D /usr/local/lib/libtirpc.so.3.0.0 | grep -i xdrmem_create
0000000000012e04 T xdrmem_create

..with LIBS="-lnsl" it fails with:

Code: [Select]

/tmp/ccFyMhli.ltrans0.ltrans.o: In function `XdrUtil_Deserialize':
<artificial>:(.text+0xf52): undefined reference to `xdrmem_create'

[andyj]

Tried that already. The problem is that the configure scripts I've come across expect the version to be at the end:

Code: [Select]

ldd (GNU libc) 2.26
which gives 2.26, versus

Code: [Select]

GNU C Library (GNU libc) stable release version 2.26, by Roland McGrath et al.
which gives "al." when then breaks the math. Besides, it's how the full ldd GNU script does it so it seems they change it for every glibc update. How about this instead? A little long but it does the job:

Code: [Select]

  --version) echo "ldd (GNU libc)" $(ls /lib/libc-*.so | sed -e 's/^.*-//' -e 's/\.so//')
        break
        ;;

I believe having dnet allows the guest to know if the host's network is disconnected, which might be desirable in some cases. Using TI-RPC it does compile, so I'm going to go with that for now, and add it as a dependency.

[Juanito]

OK - could you submit the change as a patch please?

[andyj]

Here we go.

Thanks

[uli]

Excellent piece of work.

Almost easily brought up on Hyper-V Gen2 (x64).

EXCEPT  scsi_transport_fc.ko is missing. Therefore it is not possible to start from .iso right away.

Those who are using Tc x64 on Hyper-V would probably go for Gen2 machines, therefore it would make a lot of sense to add the missing lib to the x64 version, given that all Hyper-V drivers are already there.