Tiny Core Linux
Tiny Core Base => Raspberry Pi => Topic started by: PDP-8 on May 15, 2017, 03:25:22 AM
-
I don't know if this is PiCore 9.0 specific, but I do use the DILLO browser quite a bit with my RPI2 for what I do.
Noticed that downloads initiated by clicking on a link will start, and then get immediately aborted. I believe Dillo is using wget with a lua/fltk frontend for it's download feature.
Not a showstopper as using wget in a terminal works, but wondering why Dillo itself aborts all downloads...
I've checked my dillorc file, but can't find anything immediately wrong. I am also able to download with earlier versions, like 3.0.3 on other distros. (but sure wish they'd use 3.0.5!)
Kind of scratching my head a little but I saw a patch for wget somewhere, and wondered if this is what that patch was for! :)
-
Using tinycore version 4 I had the same issue with Dillio. Solved it by downloading and installing wget.tcz. Seemed the wget in busybox was the issue.
-
Thanks gwalther! That fixed it.
Actually I had to install wget along with libunistring to get it to work.
Since I'm trying not to stray too far from busybox, and the busybox wget works fine in a terminal, I'll probably stick to that, but thank you very much anyway!
Now I just have to figure out if I need to:
1) File a bug report with Dillo
2) File a bug report with Busybox
3) Or figure out if my *own* piCore configuration is not setup right to allow the busybox version of wget to work. :)
Seriously, thanks for the help!
-
Well, if Dillo need wget.tcz to work correctly the solution is to add wget.tcz to the dep list.
-
Yes, wget along with libunistring brings it to life. Just kind of hoping that busybox's version would work.
Not a showstopper as I can use BB's wget in the terminal. Not as pretty though. :)
-
Well, if Dillo need wget.tcz to work correctly the solution is to add wget.tcz to the dep list.
This hasn't been fixed yet.
Sorry for bump but I just encountered on X86 Tinycore and did a lot of troubleshooting with checking permissions before finding this post.
Not sure if I should email nitram since he last modified the tcz or if the dependency edit is done by whoever uploads to repository.
If it hasn't been added since all other Dillo functionality works other than downloads, maybe there should be a comment in tcz description.
-
wget added to dillo dep file in tc-8.x x86 repo and dillo3 dep file in picore repos
-
Hi,staff!
May be posting in this topic is late a little, but the problem described in the topic header is present, dillo still aborts downloads.
In TC9, and probably in TC10 too.
This trouble is caused by wget.tcz, now wget.tcz can not work properly with https.
Currently, wget is using gnutls for https, but it doesn't work. I've made my own wget extension using openssl instead of gnutls, and the problem disappeared.
I used wget 1.20.3 sources and build wget with "--with-ssl=openssl" option.
I don't know what exactly is wrong with gnutls.tcz (gnutls3.6 too), maybe some changes in the outer world, wide implementation of TLS 1.3 version everywhere without options to downgrade it during data exchange.
But it seems to me, that wget is one of the basic tools, and it is prefered to make it work out of the box. I didn't checked the whole repo, but at least wget.tcz is dependancy of dillo and get_youtube-dl, so now both this extensions don't work properly.
Maybe, the right way would be to try the newest gnutls 3.6.7? I didn't done this yet, but the simplest way is to recompile wget with openssl, as openssl is widely used by other extensions too, so it will not cause exsessive memory usage for extra extensions.
I like TinyCore very much, and i think, that newcomers may be disappointed with broken wget and dillo, beside both of them are great software.
Am I right?
-
Are you speaking of piCore or x86?
-
Oh, sorry, i posted into Picore topic ((( I was hooked by topic name. I am on TinyCore. Sorry, once again.
-
wget updated in x86 repo
-
Is it possible to get rid of this annoying "Dillo HTTPS: Missing issuer certificate!" ?
-
wget updated in x86 repo
Thanks, Juainito! Works perfect.
-
Is it possible to get rid of this annoying "Dillo HTTPS: Missing issuer certificate!" ?
I can agree, that this message brings zero information, as Dillo is declared not supporting https at all. Only emulating it, i guess this is the only need to put openssl in dillo's dependancies.
-
Is it possible to get rid of this annoying "Dillo HTTPS: Missing issuer certificate!" ?
Returning to this message.
I was wrong, saying that dillo don't deal with https, basic support is present, being an ALPHA one.
I've loaded sources from dillo.org, and in the file dpi/https.c found, that certificates path is written permanently as "/etc/ssl/certs/". After changing to
it "/usr/local/etc/ssl/certs/" and compiling and packing i've recieved the mydillo.tcz finding certificates at their place, and though without such messages.
How it can be done in the right way for TC? I must mention, that I use TC9, but in TC10 it must be the same.
Juanito, if You will have the time, will You be able to rebuild the dillo.tcz in a right TC way? Of course such hardcoding is a bad taste, but it is faster, than making commit to dillo sources, as they are not changing for maybe 3 or more years.
Thanks in advance!
-
Please send a pm to the last maintainer - nitram - requesting that they make the required changes.
-
jazzbiker thx for the solution. Fast and easy workaround for TC10 x86
sudo ln -s /usr/local/etc/ssl /etc
-
Fast and easy workaround for TC10 x86
sudo ln -s /usr/local/etc/ssl /etc
Hi, neonix! Thanks for a good lesson ) Links are great! Everywhere and especially in TC!
Did you meant
sudo ln -s /usr/local/etc/ssl /etc/ssl?
The only sorrow is to change beautiful TC's /etc ( Recompiling will leave it untouched.
I will propose both methods to nitram, as Juanito adviced.
-
Please send a pm to the last maintainer - nitram - requesting that they make the required changes.
Done, thanks! I've sent neonix's proposition too. But nitram was last active at March 15, 2017 (
-
Certs in tc10 have moved to /etc/ssl/certs, as there are other applications that were hard coded there too.
-
Hi, neonix! Thanks for a good lesson ) Links are great! Everywhere and especially in TC!
Did you meant
sudo ln -s /usr/local/etc/ssl /etc/ssl?
Both works the same way. Here is proper script for TC 9.x86 and TC 10.x86 users:
sudo ln -s /usr/local/etc/ssl /etc/ssl
tce-load -iw ca-certificates.tcz
tce-load -iw dillo.tcz
-
Is it possible to redirect mp4 url to mplayer from Dillo when I click mp4 link? As I remember old Opera (Presto) has such function.
-
It would be easier to add this symlink to ca-certificates.tcz in TC10 instead to dillo.tcz, because there are many programs that will use this directory also.
sudo ln -s /usr/local/etc/ssl /etc/ssl
-
I believe you're speaking of Core/CorePure64 rather than piCore?
If this is the case, then no, it would be better to fix dillo with a patch so that it looks for the certs in /usr/local/etc/ssl - the few programs that look in the wrong place are mostly closed source binaries compiled on other distros.
-
I'm trying to compile Dillo 3.0.5 on TC11.x (x86_64) and after
tce-load -iw wget compiletc squashfs-tools fltk-1.3-dev openssl-1.1.1-dev
cd /home/tc
/usr/bin/wget http://www.dillo.org/download/dillo-3.0.5.tar.bz2
tar xf *.tar.bz2
cd dillo-3.0.5
#In dpi/https.c replace "/etc/ssl/certs/" with "/usr/local/etc/ssl/certs/"
export CFLAGS="-mtune=generic -Os -pipe"
export CXXFLAGS="-mtune=generic -Os -pipe"
export LDFLAGS="-Wl,-O1"
./configure --prefix=/usr/local --enable-ssl --disable-ipv6 --localstatedir=/var
and I get:
checking for libpng-config... /usr/local/bin/libpng16-config
checking for libpng version... 1.6.34
checking openssl/ssl.h usability... yes
checking openssl/ssl.h presence... yes
checking for openssl/ssl.h... yes
checking for SSL_library_init in -lssl... no
configure: WARNING: *** No libssl found. Disabling ssl support.***
checking iconv.h usability... yes
checking iconv.h presence... yesWhat is "SSL_library_init"?
-
Maybe dillo is expecting openssl-1.0.x and not openssl-1.1.x?
-
Maybe dillo is expecting openssl-1.0.x and not openssl-1.1.x?
I found this:
https://wiki.openssl.org/index.php/Library_Initialization
There are two ways to initialize the OpenSSL library, and they depend on the version of the library you are using. If you are using OpenSSL 1.0.2 or below, then you would use SSL_library_init. If you are using OpenSSL 1.1.0 or above, then the library will initialize itself automatically. Optionally you can explicitly initialise it using OPENSSL_init_ssl or OPENSSL_init_crypto. A compatibility macro exists in ssl.h that maps SSL_library_init to OPENSSL_init_ssl, so you can continue to use SSL_library_init if desired.What should I do now? Is it possible to put openssl-1.0.x in TC11?
-
Since the new lib will automatically initialise, you can hack the configure script and remove the check for SSL_library_init in -lssl?
-
I hacked configure, but it give error during compile process.
https.c: In function 'handle_certificate_problem':
https.c:479:38: error: dereferencing pointer to incomplete type 'X509' {aka 'struct x509_st'}
479 | if ((cn = strstr(remote_cert->name, "/CN=")) == NULL) {
| ^~
make[2]: *** [Makefile:769: https.o] Error 1
make[2]: Leaving directory '/home/tc/dillo-3.0.5/dpi'
make[1]: *** [Makefile:403: install-recursive] Error 1
make[1]: Leaving directory '/home/tc/dillo-3.0.5'
make: *** [Makefile:736: install-strip] Error 2
tc@box:~/dillo-3.0.5$
I'm not skilled enought to edit source code. Maybe shared library will be solution?
-
That is a version incompatibility, the same error has been seen in many other projects too. You'll have to wait for Dillo folks to update the code to work with openssl 1.1 (or maybe they already have, try the git versions, etc).
-
dillo-beta.tcz from git is already in TC11 repo, but some websites work better in 3.0.5 version.
-
dillo-beta.tcz from git is already in TC11 repo, but some websites work better in 3.0.5 version.
And tinycorelinux.net is among those sites (
Fifth is compiled for openssl-1.0 too, and in TC11 shows the message making me sad :
fifth: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
Will it be fifth with openssl-1.1.x? @Curaga, if I have some chances to help, i will do my best, please.
-
Hi, neonix!
There is the patch in dillo source repo, named "Support OpenSSL 1.1.0 3.0.5" dated by 06 Apr 2018. Did You tried it?
Edit: https://hg.dillo.org/dillo/rev/b171b8610400
-
Thanks folks, I was able to compile working version thanks to your tips.
I had to hack configure file and add patch to https.c.
About Fifth browser. Does TinyCore Team is engaged in development of this browser?
How to contact with the developers? The project shows great promise, but it still has many bugs. The last version was released "0.5.1 @ Apr 9, 2016".
-
Fifth is compiled for openssl-1.0 too, and in TC11 shows the message making me sad :
fifth: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
Will it be fifth with openssl-1.1.x? @Curaga, if I have some chances to help, i will do my best, please.
About Fifth browser. Does TinyCore Team is engaged in development of this browser?
How to contact with the developers? The project shows great promise, but it still has many bugs. The last version was released "0.5.1 @ Apr 9, 2016".
I am the primary/lone developer of Fifth. I'm unfortunately still very low on time, and webkit stuff takes ages to work on, mainly due to huge compile times, but also the complexity.
So new versions with more recent webkit or even openssl 1.1 support may not come soon.
-
until curga will update his very good FIFTH browser in TC11_x64, we can use it, by manualy loading the old missing library from tc10_x64, like this:
tc@box:~$ fifth
fifth: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
tc@box:~$ tce-load -i openssl.tcz
openssl.tcz: OK
tc@box:~$ fifth
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: profile 'Photoshop ICC profile': 'RGB ': RGB color space not permitted on grayscaleEDIT:tc@box:~$ fifth
Crash recovery
Crashing with signal Segmentation fault, 11tc@box:~$nope, it seems that next time it will crash :(
-
That's because curl links a different version of libssl, and having two versions of the same library at once, in the same program -> crash. You need to go further, grab the older curl etc as well, as long as there are two conflicting versions.
-
That's because curl links a different version of libssl, and having two versions of the same library at once, in the same program -> crash. You need to go further, grab the older curl etc as well, as long as there are two conflicting versions.
Could you copy and paste Fifth browser from TC10.x x86 to TC15.x x64 with needed dependencies, without recompilation process?
-
Yes, as long as all needed deps are grabbed too.
-
Hi neonix
Could you copy and paste Fifth browser from TC10.x x86 to TC15.x x64 with needed dependencies, without recompilation process?
If you are running Core (32 bit kernel, 32 bit apps), you can only run 32 bit programs.
If you are running Core64 (64 bit kernel, 32 bit apps), you can only run 32 bit programs.
If you are running Corepure64 (64 bit kernel, 64 bit apps), you can only run 64 bit programs.
Core64 is not in the release section of the repo. You would need to make it yourself:
cat rootfs.gz modules64.gz > core64.gz
-
I meant TC10_32 to TC15_32. Sorry for typo.
-
Yes, as long as all needed deps are grabbed too.
I tested Fifth browser from TC10 in TC15 and get "error 27, out of memory". It's SSL error I believe.