Tiny Core 10.0 Alpha 2 Testing

[Juanito]

Team Tiny Core is pleased to announce that Tiny Core 10.0 Alpha2 is available for public testing:

http://repo.tinycorelinux.net/10.x/x86/release_candidates/
http://repo.tinycorelinux.net/10.x/x86_64/release_candidates/

This is an alpha level cut. If you decide to help test, then please test carefully. We don't want anyone to lose data.

Since this is an alpha cut, we ask that only experienced users test. This cut is not for general use. The features in any alpha are not fixed and may change before a public release candidate is available.

Most extensions have been copied over from the 9.x repo

We appreciate testing and feedback.

If you use distribution files note that you need a new vmlinuz and core.gz (or rootfs.gz + modules.gz)

Changelog for 10.0 alpha2:
* added missing libpthread symlink
* updated /etc/os-release

Changelog for 10.0 alpha1:
* kernel updated to 4.19.10
* glibc updated to 2.28
* gcc updated to 8.2.0
* e2fsprogs base libs/apps updated to 1.44.4
* util-linux base libs/apps updated to 2.32.1
* busybox updated to 1.29.3
* busybox patched for vi search bug

[andyj]

Compiling PHP 7.3 apache module on 32-bit fails with this:

Code: [Select]

/usr/local/bin/ld: ext/filter/.libs/sanitizing_filters.o: unsupported non-PIC call to IFUNC `php_addslashes'                                     
/usr/local/bin/ld: ext/standard/.libs/base64.o: unsupported non-PIC call to IFUNC `php_base64_encode'                                             
/usr/local/bin/ld: ext/standard/.libs/string.o: unsupported non-PIC call to IFUNC `php_addslashes'                                               
/usr/local/bin/ld: ext/standard/.libs/http_fopen_wrapper.o: unsupported non-PIC call to IFUNC `php_base64_encode'                                 
/usr/local/bin/ld: ext/standard/.libs/streamsfuncs.o: unsupported non-PIC call to IFUNC `php_addslashes'                                         
/usr/local/bin/ld: ext/standard/.libs/password.o: unsupported non-PIC call to IFUNC `php_base64_encode'                                           
/usr/local/bin/ld: main/.libs/main.o: unsupported non-PIC call to IFUNC `php_base64_decode_ex'                                                   
/usr/local/bin/ld: main/streams/.libs/memory.o: unsupported non-PIC call to IFUNC `php_base64_decode_ex'                                         
/usr/local/bin/ld: final link failed: nonrepresentable section on output                                                                         
collect2: error: ld returned 1 exit status                                                                                                       
make: *** [Makefile:215: libphp7.la] Error 1                                                                                                     

This is a new one on me. Maybe an overly aggressive optimization?

[Leee]

I'm getting md5sum errors on modules.gz and modules64.gz

[Juanito]

checksums corrected - thanks

[Juanito]

Compiling PHP 7.3 apache module on 32-bit fails with this:

ld failures are often due to lto or ld.gold, but if it compiles 64-bit then it is unlikely to be that.

google doesn't throw up any hits 

[Rich]

Hi Juanito

... google doesn't throw up any hits 

Stripping the error message to make it a little less specific returns some results. Try searching on this:

Code: [Select]

unsupported non-PIC call to IFUNC

[Juanito]

https://pld-devel-en.pld-linux.narkive.com/IPOLc9VF/php-7-3-legacy-architectures

..says "Looks like wrong conditions in hand-written asm code."

..and ends with "i'm pretty ok to just to have ExclusiveArch: %{x8664} for 7.3 branch"

It looks like a php-7.3 problem that they don't want to fix for x86?

[Rich]

Hi andyj
You could try adding this when you  ./configure  :

Code: [Select]

--with-picI'm basing this suggestion on posts 2 and 3 from the link Juanito provided.

[andyj]

Actually, --with-pic=both is the default, which is causing the problem. I don't know why the articles you referenced weren't returned in my searches. Maybe it's a geography thing. Anyway, following the hints lead me to try the undocumented --with-pic=0 setting (never did find the list of choices), which allows it to compile. I see -fPIC for many other packages so I don't know why it's a problem for PHP. I still need to run "make test/check" for the packages that have it. Unfortunately I don't have Oracle or SQL Server databases at my new location yet so I can't test PHP against those.

[andyj]

I'm not sure why but the PHP tests for the pspell extension (using aspell) hang on both 32-bit and 64-bit. Strace says they're hanging on futex_wait_private, but I don't know who or what they're waiting for. Does Aspell need to be recompiled?

[Juanito]

aspell was recompiled recently with a couple of fixes for gcc-7.x.

The commits in git do not show any more recent fixes for gcc.

[andyj]

In prior versions PHP tests never hung, they always got through all 15k+ eventually. This time all pspell and at least one in libgd, mysql, and enchant, and maybe others I don't remember. I don't know what's wrong, but something is not right.

[polikuo]

I noticed there isn't an installer in the ISO. I don't suppose that with a new version we could tweak the installation paths so that adding 64-bit to a 32-bit install would be easy, that is move boot to the root of the boot drive and out of a tce directory, and make the tce directories tce32 and tce64.

I have refactored the script, but I haven't test it.
See my github
Does anyone care to test it?
I'm kinda on a tight schedule.

The variables have been adjusted, which should be fine.
The tce path should be either tce32 or tce64
As for the "boot" path ...
IIRC, corebook has stated that since some users might install multiple OSs on the same partition,
thus the "boot" directory is stored in "tce" directory to prevent conflict.

[Juanito]

I'm not sure why but the PHP tests for the pspell extension (using aspell) hang on both 32-bit and 64-bit. Strace says they're hanging on futex_wait_private, but I don't know who or what they're waiting for. Does Aspell need to be recompiled?

Recompiled aspell (patched for a non-fatal compile error) posted to the 10.x x86_64 repo - could you check if that improves things?

[andyj]

In testing other extensions which use perl for that purposed it complains that LC_ALL isn't set. According to /etc/profile, it's exported provided that it's set in /etc/sysconfig/language, but when that file is created in /etc/init.d/tc-config and only LANG is set. It doesn't set a default LC_ALL, and it doesn't have any code to grab it from the kernel command line that I can see. Maybe at least for now add LC_ALL=C to /etc/sysconfig/language in /etc/init.d/tc-config?