Tiny Core 12.0 Alpha 2 Testing

[jazzbiker]

so partial gain from new compiler or new basic libs.

In my experience extension recompiling for new version leads to the gain in size

[andyj]

That isn't the latest patch? The one in 5.10-patches was adjusted.

I downloaded the "patched" kernel source tarball from the TC website along with the config file and did the customary "make bzImage modules". I didn't check to see if the patch on the website is the same one applied to the kernel source code tarball, but it's the tarball for sure that's the problem.

[GNUser]

P.S. I hope these reports are still helpful to you guys.

Yes 

Good to know

Presuming you were referring to x86_64 in both cases...

Yes, all my testing was on x86_64. Sorry if I forgot to mention it somewhere.

* goffice has a dep on libffi6 and not gnumeric

Oops. I should have dug deeper into that one. Thanks for catching it.

[andyj]

I hadn't noticed at first, but after several years of treating rpc as depreciated, it was removed from glibc-2.32.

I didn't notice that it was an upstream change. Supposedly the latest open-vm-tools has been fixed to deal with this, but it isn't working for us right now. So, no simple fix....

[Juanito]

rpcsvc-proto, which provides rpcgen, posted

[Juanito]

I've copied from x86 TC11 and checked

Extensions copied over from both lists - lua depends on readline and so will need recompiling as will netsurf.

[curaga]

I downloaded the "patched" kernel source tarball from the TC website along with the config file and did the customary "make bzImage modules". I didn't check to see if the patch on the website is the same one applied to the kernel source code tarball, but it's the tarball for sure that's the problem.

Oh my, I wonder how I managed that. Uploading the fixed tarball.

[andyj]

rpcsvc-proto, which provides rpcgen, posted

This and the updated libtirpc gets me to what looks like a working open-vm-tools-desktop. Except that I had to cheat a little and copy some extensions from 11.x, like wayland which by the way is linked to libffi6. I still haven't figured out why wayland is required on 32-bit only.

[Juanito]

Strange - x86 mesa is not compiled against wayland to avoid bloat.

[curaga]

Upload done. The old tarball was 115726264 bytes with a md5sum of
c4054dbb8d667ec2b2a8ec9acba3a344

The new one is 115727052 bytes and
be189fbe932659e8c58636cde5b97df2

[Juanito]

lua depends on readline and so will need recompiling as will netsurf.

updated lua posted - netsurf is statically linked, it was gtk2 that needed recompiling for the updated libffi.

[jazzbiker]

netsurf is statically linked, it was gtk2 that needed recompiling for the updated libffi.

Hi, Juanito!

ldd really reports, that netsurf-gtk binary is statically linked, but in this case it will not need any dependencies, which is not true. In fact I think binary inside extension tree was compressed with some software  before squashing the extension tree.
I've compiled netsurf 3.10 (current is 3.9) according to the reciept in /src and got the netsurf-gtk binary twice bigger than in the current netsurf.tcz, but resulting .tcz size was nearly the same.
I've already sent the PM to @neonix and asked him to update the extension. I've asked him not to use intermediate compession, because it don't reduces the resulting .tcz size.

[Rich]

Hi jazzbiker
I see no commands that would indicate use of intermediate compression being used:
http://tinycorelinux.net/11.x/x86/tcz/src/netsurf/netsurf.tcz.build-dep
http://tinycorelinux.net/11.x/x86_64/tcz/src/netsurf/netsurf.tcz.build-dep

There are 3 make commands listed. One for framebuffer, one for GTK2, and one for GTK3. The versions in TC10 and TC11
were the GTK2 versions. Is it possible your size increase was because you ran more than one of the make commands?
The only executable in your destination should be  usr/local/bin/netsurf-gtk.
If you also see  usr/local/bin/netsurf-gtk3  or  usr/local/bin/netsurf-framebuffer  you ran too many make commands.

I also don't see any  strip  commands, unless those are in the  make  file.

[jazzbiker]

Hi, Rich!

No, I made only TARGET=GTK2. By the way makefile rejected TARGET=GTK, probably is version 3.10 refinement.
Sorry, I don't understand how netsurf-gtk binary can be statically linked. Doesn't it really need no dependencies? That was my main surprise and this accompanied with the less size make me think, that it is compressed with some additional (self-extracting in memory?) software. Of course, I may be wrong, I'm just guessing. But  I can not imagine that it is statically linked with gtk2, really. In this case it must be much bigger and doesn't needs the .dep file at all. Sorry, if I am misunderstanding the meaning of "static linking". But when I made the 3.10 version according to the build reciept, ldd reported me the long list of .so dependencies, as usual. I was building under TC11 so libffi.6 was present in netsurf-gtk2 dependencies. I used sstrip.
I'm sorry I'm distracting You from TinyCore release, because of my unnecessary curiosity. Maybe @neonix knows better and will answer my questions.

[Juanito]

If, on the other hand, the wireguard kernel module is part of TCL12 base system, then  wireguard-KERNEL.tcz  should be removed from  wireguard-tools.tcz.dep.

wireguard-tools copied over and deps adjusted