Tiny Core Linux
Tiny Core Base => TCB News => Alpha Releases => Topic started by: Juanito on December 27, 2018, 03:35:04 AM
-
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
-
Compiling PHP 7.3 apache module on 32-bit fails with this:
/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?
-
I'm getting md5sum errors on modules.gz and modules64.gz
-
checksums corrected - thanks
-
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 :(
-
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:
unsupported non-PIC call to IFUNC
-
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?
-
Hi andyj
You could try adding this when you ./configure :
--with-picI'm basing this suggestion on posts 2 and 3 from the link Juanito provided.
-
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.
-
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?
-
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.
-
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.
-
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 (https://github.com/polikuo/tc-install)
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.
-
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?
-
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?
-
Could you propose a patch?
-
Here's a patch. This is the behavior I don't understand:
tc@box:~$ localedef --list
en_US.utf8
tc@box:~$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
tc@box:~$ locale -a
C
en_US.utf8
POSIX
tc@box:~$
Why are all the LC_* variables set but not LC_ALL and where does this happen?
Regarding php/pspell, thanks for the update. Unfortunately it didn't fix the futex hang in the pspell_check function. I tried changing gcc optimization to -O2 instead of -Os, but that didn't help.
-
I recall reading somewhere that $LC_ALL (and $LANGUAGE) being unset was the default behavior in order to allow the other $LC_* settings to be overridden without having to change them all?
-
That seems reasonable and I don't doubt it based on what I was able to find. As far as I know perl is the only thing complaining, and I'm only using perl because some of the "make test" are written in perl and the language setting doesn't seem to affect the test outcomes. I personally have no desire to use perl, so if you choose not to accept the patch I'm fine with that. The multiple language variables does seem to be the result of cruft from a lot of packages and lack of early standardization. But, a line exporting LC_ALL in /etc/profile when it's not being set anywhere seems like cruft too. It seems like if we're going to export it then we should set it, or if we're not going to set it then don't export it.
-
I did a bit of checking and found this in the debian wiki locale section:
Warning - Using LC_ALL is strongly discouraged as it overrides everything. Please use it only when testing and never set it in a startup file
..anyway, it's good your question prompted some thought on the subject.
-
While poking through the kernel config I noticed that "CONFIG_HOTPLUG_CPU=y", but "# CONFIG_MEMORY_HOTPLUG is not set". Granted that both of these are probably just for VM's, but it does seem that if we have one we should probably have the other.
-
VMs usually use the balloon drivers to dynamically adjust RAM.
-
As far as I can tell, ballooning is meant to recover RAM in an overcommit situation. If I increase the ram for a VM from 4 to 8 GB for instance and I'm still not overcommitted, I'll have to reboot for the VM to see it because the kernel isn't hot-add-memory capable. This isn't a ballooning situation.
-
I've determined that the problems with php-pspell began when aspell was recompiled against ncursesw. When I load the old aspell the tests don't hang. What other compile options for aspell were used?
-
see:
http://www.tinycorelinux.net/10.x/x86_64/tcz/src/aspell/compile_aspell
http://www.tinycorelinux.net/9.x/x86_64/tcz/src/aspell/compile_aspell
http://www.tinycorelinux.net/5.x/x86_64/tcz/src/aspell/compile_aspell
-
Yes, ballooning requires you to set it in advance. You might set "use 2GB right now, but 8GB max". Hotplug would be required for the case you showed.
-
Ballooning for VMware at least is a server feature. I don't know that it is supported in workstation, but workstation will let me add memory.
For aspell, by trial and error I found that adding --enable-compile-in-filters to configure it works with php. Of course that begs the question, what about loading filters causes it to hang?