Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: gavs on January 31, 2014, 12:36:21 PM
-
Trying gmpc.tcz ftom TC4.x in TC5.2. One missing dependency in the TC5.x repo, gnutls2.tcz. I got that from the TC4.x repo. After installing gnutls2 and gmpc I get an error when trying to start gmpc. It is looking for libpng12. TC5.x includes version 1.6 of libpng.
Question 1: Does this mean gmpc should be compiled in TC5.x?
Since I am interested in an updated version of GMPC, I tried building in TC5.2 (I had sent a pm to maintainer but have not heard back). Two dependencies needed for building were missing in the TC5.x repo, gob2.tcz and libunique-dev.tcz. I got these from the TC4.x repo and tried to build. Configuration completed but when I tried 'make' I got an error message that it could not find libpng12.la.
Question 2: Was this error due to using gob2 and/or libunique from the TC4.x repo which were built with libpng version 1.2?
Question 3: If the answer to Question 2 is NO, does it mean there is reference to libpng12 in the GMPC source and I should contact the author to ask if he can update?
-
One way to check the dependencies of tc-4.x extensions in tc-5.x is to download and mount the extension squashfs in tc-5.x:
$ mkdir /tmp/test /tmp/image
$ cd /tmp/test
$ wget -c http://repo.tinycorelinux.net/4.x/x86/tcz/gmpc.tcz
$ sudo mount gmpc.tcz /tmp/image
$ ldd /tmp/image/usr/local/bin/gmpc | grep png
libpng12.so.0 => not found..so to answer your question 1, yes gmpc would need to be recompiled in tc-5.x against the updated libpng and the updated gnutls.
To answer question 2, gob2 does not depend on libpng, but libunique does depend on libpng and so would need to be recompiled for tc-5.x.
It's effectively already answered, but for question 3, yes an update to the gmpc extensions is required - the gmpc source should find and link against libpng16, but the older the source the more likely it is that there may be problems.
-
Thank you for the hint on how to easily check dependencies and for the advice about getting gmpc to work.
I will follow these steps:
1. Send pm asking if maintainer of libunique (Arslan S.) would comile/update against TC5.x
2. Try to compile gmpc with updated libunique.
2.a. If successful, I will try to build the .tcz of gmpc version 11.8 compiled against TC5.x and submit.
2.b. If unsuccessful, I will contact gmpc author and ask if updating source to libpng16 is possible.
2.c. Anticipating that updating gmpc source might not be easily or immediately available, I saw reference to co-existence of libpng12 with libpng16 to support legacy software.
Question: Is it sensible to think of copying libpng from TC4.x repo, unsquashing, removing any redundant links, and squashing as new libpng12.tcz?
-
Let's try the gmpc re-compile first ;)
-
OK. I guess proper etiquette is to wait a few days for libunique maintainer to respond (I sent a pm asking if they could recompile in TC5.x). When I get a reply I can try to re-compile gmpc.
By the way, should/could gob2.tcz be copied from the TC4.x repositories to the TC5.x?
-
Hi gavs
Arslan S. hasn't been active since last May, so you might want to try compiling anyway.
By the way, should/could gob2.tcz be copied from the TC4.x repositories to the TC5.x?
It would be better to make sure it doesn't cause any problems with gmpc first.
-
Unsuccessful attempt to build libunique.
I installed compiletc.tcz, gtk2-dev.tcz and dbus-glib-dev.tcz. Configuration complained about missing 'gl' package required by cairo. I installed glu-dev.tcz.
Question: Was this the correct choice?
Configuration completed after glu-dev was installed. Make then reported the following error:
CC libunique_dbus_la-uniquefactory-dbus.lo
uniquefactory-dbus.c: In function 'unique_factory_dbus_send_message':
uniquefactory-dbus.c:71:3 error: g_value_array_get_nth' is deprecated (declared at /usr/local/include/glib-2.0/gobject/gvaluearray.h:65): Use 'GArray' instead [-Werror=deprecated-declarations]
This was repeated 4 more times with 72, 73, 75 and 76 in place of 71.
Question: Is there something I can do to make this work or does this mean that libunique will not compile in TC5.x?
-
does the patch on the blfs (svn) page for libunique help?
-
Thank you for the tips and your patience.
I got the following patch:
http://www.linuxfromscratch.org/patches/blfs/svn/libunique-1.1.6-upstream_fixes-1.patch
I also got autoconf.tcz from the TC5.x repo and re-extracted the files for libunique-1.1.6 using tar.
I entered:
$ patch -Np1 -i ../libunique-1.1.6-upstream_fixes-1.patch
and I see the messages 'Possibly reversed hunk 2 at 288, Hunk 2 FAILED 23/23.' and 'Possibly reversed hunk 1 at 141, Hunk 1 FAILED 12/12.'
I suppose not surprisingly, when I entered:
$ autoreconf -fi
I see the message 'failed to run aclocal: No such file'
What did I do wrong?
-
Hi gavs
I see an aclocal in automake.tcz
-
maybe you've figured it out already, but because of the poosibility of needing the lib for another use
I built libunique-1.0.so in corepure64-5.2
I needed many more deps than expected
these wererequired to build
gtk2-gir.tcz
gtk2-dev.tcz
atk-dev.tcz
libtool-dev.tcz
gobject-introspection-dev.tcz
atk-gir.tcz
gdk-pixbuf2-gir.tcz
pango-gir.tcz
these were already loaded &/or run (whether they were neeed or not)
linux-kernel-sources-env.tcz
compiletc.tcz
automake.tcz
findutils.tcz
bash.tcz
ncurses-dev.tcz
perl5.tcz
Appeared to be successful using the same patch, configure, make & make install as in LFS
-
Inching ahead, but not there yet.
I added the dependencies suggested by Coreplayer2. This time the patch command seemed to complete successfully. The output was several lines saying 'patching file ...' without any warning or error messages. Thank you Coreplayer2.
I am still getting a warning/error(?) message from the autoreconf command. As Rich noted, I confirmed that there is an /usr/local/share/aclocal directory. I should have been more careful about reporting the error message. The exact message is:
Can't exec "aclocal": No such file or directory at /usr/local/share/autoconf/Autom4te/FileUtils.pm line 326.
autoreconf: failed to run aclocal: No such file or directory
I took a look at FileUtils.pm in the vicinity of line 326, but I could not decipher what the problem might be. I did not try the make after this message. Didn't know if I should ignore the message and push on.
-
Can't exec "aclocal": No such file or directory at /usr/local/share/autoconf/Autom4te/FileUtils.pm line 326.
autoreconf: failed to run aclocal: No such file or directory
Did you install automake.tcz ?
-
Hi gavs
And is autoconf.tcz installed?
-
Thank you for the prompt responses. I did have autoconf.tcz installed but I did not know about automake.tcz. After loading automake the autoreconf command appears to have executed. Some warning messages about 'no AC_LANG_SOURCE call detected' and 'INCLUDES is the old name for AM_CPPFLAGS'. I assume these are not serious.
The linuxfromscratch site indicates use of some options for configuration that I have questions about.
Question 1. Suggested --prefix=/usr. Should I keep the default /usr/local?
Question 2. Suggested --disable-dbus. Should I omit this? I have the dbus-glib extension loaded.
Question 3. Suggested --disable-static. Should I use this or omit?
-
Exactly... I use automake which installes autoconf , otherwise the build will complain about autoreconf which is part of autoconf.
Also the build log specifically used bash at some point, maybe because bash was installed and is now the shell...?? Was strange to see a command using bash in the log though
-
Please use prefix=/usr/local it is the TC standard.
You can disable static, probably no one need static build later. It will reduce -dev size. In worst case you can rebuild it with static :)
dbus is used by desktop environments like Xfce, Gnome, KDE, not in the basic GUI. You can disable. See note above :)
-
Thanks to everyone, compilation of libunique completed without error, as far as I can tell. I will adjust permissions, set root:root as owner, split out the dev files using the TC4.x as a guide (I do not know what is dev and what is not), strip to reduce file size and use mksquash to make the extensions. If all goes well I will try to submit.
There was a bit of difference in the files created that I have questions about.
Question 1. The file /usr/local/lib/libunique-1.0.a was not created. This file was in libunique-dev for TC4.x. Is this OK?
Question 2. Directories /usr/local/share/gir-1.0 and /usr/local/lib/girepository-1.0 were created. Should I include these in libunique or libunique-dev? They were not present in the TC4.x extensions.
-
Put gir files to libunique-gir.tcz
Put include, *.a, *.la, pkgconfig to libunique-dev.tcz if they exist.
Study extensions in the repo, try to enable/disable static and look for diffrenece. It will help :)
-
Thank you bmarkus for the hints. After some investigation, I am guessing that the *.a file (which I found out was a static library file) was not generated because I used the option --disable-static in the configuration.
I made some progress. I built libunique in TC5.x. With this, I was successful in building gmpc in TC5.x. But perhaps, even though the make worked, everything is not well. Starting with a clean TinyCore, I installed alsa.tcz, mpd-minimal.tcz (I was able to build this extension in TC5.x) and gmpc.tcz. The alsa command speaker-test gives output, so alsa should be working. I started mpd and it created its database and did not report any error. When I tried to start gmpc it complained about missing libunique-1.0.so. Libunique had not been listed as a dependency in TC4.x. I added it. I also the dependency gnutils2.tcz to gnutils.tcz. They look similar but it appears that gnutils is a newer version? When I tried gmpc again I get the following error:
** (gmpc:10576): Warning **: Unable to open a connection to the session bus: Cannot spawn a message bus without a machine-id: Unable to load /var/lib/dbus/machine-id or /etc/machine-id: Failed to open file '/var/lib/dbus/machine-id': No such file or directory
(gmpc:10576): GLib-GIO-CRITICAL **: g_dbus_connection_call_sync_internal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
Does this have anything to do with using the configuration option --disable-dbus? Since that option made GDBus default, is there a missing dependency?
-
As mentioned a couple of posts back, there is more recent version of gnutls in tc-5.x - if you compiled libunique and gmpc on tc-5.x then there should be no problem with this and you just need to update the dep file to reference gnutls rather than gnutls2.
Although you compiled libunique without the dbus dep, it seems like gmpc is looking for dbus - did you try loading the dbus extension and starting the daemon?
-
Thank you Juanito, loading dbus.tcz worked. I had compiled libunique, libmpd and gmpc in TC5.x and I updated the dependency to gnutils instead of gnutils2. Now GMPC opened, connected to the mpd daemon and I was able to play music. Nice.
I will try completing all the steps needed to submit the extensions. Thanks to all.
-
Forgot to mention that this was done with gob2.tcz from the TC4.x repo.
Will that extension get copied to the TC5.x repo or is further testing needed?
-
It looks like it should work - gob2 copied to the 5.x repo
Did you manage to submit the extensions?
-
Thank you for copying gob2 to the TC5.x repo, I see it there now.
Question 1: I compiled with the gob2 that I had obtained from the TC4.x repo. I assume that I do not need to recompile and rebuild everything again with the gob2 from the TC5.x repo, since it was just a copy? Please confirm.
I have prepared the following extensions for submission:
libunique
mpd-minimal
libmpd
gmpc
gmpc-tagedit
gmpc-albumview
I have not run them through submitqc yet, but I have loaded them locally and all seems to be working. I have not heard back from the maintainers of mpd-minimal (gutmensch) or gmpc (TaoTePuh). I was holding back on submitting any extensions because when I compiled mpd-minimal I left out missing dependencies libmpcdec and wavpack (I do not use these encodings). I thought I should go back and try to include these though for consistency. I heard back from the maintainers (Jason W and bmarkus respectively) that they were not planning to do anything with these and I should go ahead and compile in TC5.x. Wavpack compiled without complication and I am in the process of preparing it. Libmpcdec was not straightforward. The tar did not contain a configure, but there was a configure.in. I guessed (perhaps wrongly??) that I could use automake/autoconf. When I tried autoconf, I got an error message for "possibly undefined macro" followed by "if this token is legitimate, please use m4_pattern_allow. There are 5 such tokens listed. I was going to do some research on the autoconf documentation to see how I would use m4_pattern_allow. Any advice welcome, as I am just fumbling through this.
Question 2. I suppose adding the missing dependencies to mpd-minimal should not have any impact on the other extensions, so I should proceed with using submitqc to check and then I guess bcrypt is recommended before e-mailing?
Question 3. Is it preferred that each of -dev, -gir, -locale, - doc and the gmpc-plugins extensions be submitted separately with their respective .info, .dep, .list and .md5.txt files or is it preferred if they are bundled in one submission per package name, e.g. libunique, libunique-dev and libunique-gir.
-
I assume that I do not need to recompile and rebuild everything again with the gob2 from the TC5.x repo, since it was just a copy? Please confirm.
Affirmative - no need to recompile
The tar did not contain a configure, but there was a configure.in.
There would normally be a script named autogen.sh that requires automake and libtool-dev to run and will create the configure script.
Question 2. I suppose adding the missing dependencies to mpd-minimal should not have any impact on the other extensions, so I should proceed with using submitqc to check and then I guess bcrypt is recommended before e-mailing?
Please go ahead
Question 3. Is it preferred that each of -dev, -gir, -locale, - doc and the gmpc-plugins extensions be submitted separately with their respective .info, .dep, .list and .md5.txt files or is it preferred if they are bundled in one submission per package name, e.g. libunique, libunique-dev and libunique-gir.
I guess it depends on the size - for large extensions submit extension by extension and for smaller ones bundle by extension name.
..and thanks for your contribution to tinycore
-
Regarding the musepack tar, I tried
$ cd musepack_src_r475
$ find -name auto*
$ find -name *.sh
Nothing was returned. Not sure where to go from here. I could just leave out libmpcdec during compile, but maybe I should pm the previous maintainer, Jason W to ask for advice on how he compiled.
I tried submitqc5 with the extensions I have prepared. Submitqc5 reports corrupt tcz files. It asks 'PLEASE VERIFY THEY ARE GOOD OR REMAKE'. Libunique was used during compilation. I have loaded mpd-minimal, gmpc and the gmpc plugins. They appear to load cleanly and I am able to play music files. Is there something further I should do to verify?
-
Would this be of any use:
http://repo.tinycorelinux.net/tcz/src/libmpcdec-1.2.6/libmpcdec-1.2.6.tcbuild
As for the 'PLEASE VERIFY THEY ARE GOOD OR REMAKE' message, I have not come across this before - maybe you could submit anyway?
-
I was able to compile libmpcdec-1.2.6. I had been trying to compile musepack_src_r475 because it is a more recent release. Apparently libmpcdec-1.2.6 uses SV7 while the newer version uses SV8. As I mentioned, I do not use this encoder, so I do not really know if the version makes a difference. Using the libmpcdec-1.2.6 maintains consistency with TC4.x so I will build that extension and submit it and use it to compile the mpd-minimal extension.
I will submit the extensions if they are working, despite the warning from submitqc5.
-
'PLEASE VERIFY THEY ARE GOOD OR REMAKE'
I've seen this before, frankly it puzzled me for a while. Though I can't remember exactly the cause off the top of my head, the best answer I can give at the moment is that it's system related. I found that the tcz squash'd archive was in perfect condition when "submitqc5" tested on other systems (I use the script below to automate the process and while unrelated it reveals also we may need to use sudo submitqc5). All I can suggest is be sure the current build system is updated and run "submitqc5" on the tcz using another system to verify (iirc the issue may have been with an x86_64 extension I had installed at the time, but I'm not sure..).
perhaps this script will help you when making many extensions,
create many directories each complete with files to test with submitqc5 then tar and submit, run
from the parent directory which will also tar the contents ready to email. once an extension tar file has been created
the script will not test the contents again, will pass up that dir and move on to the next etc etc
each time i add a new directory containing tcz and info file.I simply run the script again
-
I found a current script so updated my previous post.
Also iirc use "base" boot code perhaps avoids this corrupt message
-
Disregard the boot code "base" above, must have been a coincidence.
the issue of "PLEASE VERIFY THEY ARE GOOD OR REMAKE" apparently results from running sudo busybox mount -o loop "$F" "$TMP2" ( line 378 of submitqc5 )
Perhaps related to busybox mount since tc5.1 ?
-
Thank you coreplayer2 for the tips and the script.
I tried sudo submitqc5 but got the same message about corrupt tcz. I should also mention that the script does not complete. It reports "/usr/local/bin/submitqc5: line 435: not found".
A question about the script. I was doing chown -R root:root on the extension directory, chmod 644 for 'ordinary files' and chmod 755 for all directories and for 'executable' files, following, I believed, the wiki on creating extensions. Am I interpreting your script correctly that it sets ownership as tc:staff and permission mode as 664 (not 644) for all files, including executables? Have I been setting ownership and permissions improperly?
-
Thank you coreplayer2 for the tips and the script.
I tried sudo submitqc5 but got the same message about corrupt tcz
As said earlier sudo was unrelated to the error message, was just an FYI.
I should also mention that the script does not complete. It reports "/usr/local/bin/submitqc5: line 435: not found".
I believe this is due to a change in busybox mount. aiui submitqc5 needs a small update to rectify
-
A question about the script. I was doing chown -R root:root on the extension directory, chmod 644 for 'ordinary files' and chmod 755 for all directories and for 'executable' files, following, I believed, the wiki on creating extensions. Am I interpreting your script correctly that it sets ownership as tc:staff and permission mode as 664 (not 644) for all files, including executables? Have I been setting ownership and permissions improperly?
Maybe some confusion here, not sure why there would be any executable files in the working submit & tar up directory (as shown below)
I guess I need to ask what is the extension directory? because root:root on the working extension directory is probably not necessary
Placed in the parent dir of " my_extension_name_directory " the intention of the script is to make light work of testing the previously created extension and info files using submitqc5, then tar it up ready to submit. The script set's permissions on these files only, the contents of your extension.tcz is your business :)
besides submitqc5 will balk at you most likely if the permissions of your extension's important files are set incorrectly.
submissions_directory
place submit script here
\my_extension_name (directory)
|-- my_extension_name.tcz
|-- my_extension_name.tcz.dep
|-- my_extension_name.tcz.info
|-- my_extension_name.tcz.list
|-- my_extension_name.tcz.md5.txt
`-- my_extension_name.tcz.zsync
see http://wiki.tinycorelinux.net/wiki:creating_extensions (http://wiki.tinycorelinux.net/wiki:creating_extensions)
-
'PLEASE VERIFY THEY ARE GOOD OR REMAKE'
error has been fixed, thanks Juanito
-
Thank you for that clarification coreplayer2. I was getting confused between the files being 'tar ed' for the submission and the files being 'squash ed' for the extension.
I prepared the files for submission of the libmpcdec and the wavpack extensions. I did not notice any errors or warnings during the build. I decided to try compiling mpd again with these optional dependencies included before submitting (it was the only testing I could think of). Since the build had gone well, I was expecting no problems. I copied libmpcdec.tcz, libmpcdec-dev.tcz, wavpack.tcz, wavpack.tcz.dep and wavpack-dev.tcz to the tce/optional directory. I used the apps browser to load locally these and the other dependencies for compiling mpd. The output of ./configure reports that libmpcdec and wavpack were not found. When I look in /usr/local/lib, links to loops exist for the libmpcdec and the wavpack .so, .a and .la files. The other optional dependencies appear to be detected during mpd configuration. I am pondering what to try or check next. I suppose it is not appropriate to submit libmpcdec and wavpack until this is figured out?
While I was typing this reply, juanito posted that 'error has been fixed'. Tomorrow I will try to update submitqc5 using the apps browser and try it on these extensions.
-
I am pondering what to try or check next.
You could run ./configure and then check config.log
-
I recompiled libmpcdec from scratch, built the .tcz and the -dev.tcz again and tried ./configure for mpd. Still did not find libmpcdec. I checked the config.log for libmpcdec and there were several errors identified, despite reporting successful configuration at the end. I extracted those lines to post here, but given what I discovered subsequently, perhaps that is not useful.
I decided to get libmpcdec and wavpack from the TC4.x repo (libmpcdec is the same version and wavpack is older) and try ./configure for mpd with them. Wavpack was detected and that encoder was enabled. Libmpcdec was not enabled, same error reported. Then I checked the changelog for mpd. I discovered:
- mpcdec: reject libmpcdec SV7 in configure script
As I mentioned in a previous post, libmpcdec-1.2.6 uses SV7 while the newer musepack_src_r475 uses SV8. The musepack tar has a libmpcdec directory, but there are no configure or autogen scripts in this directory or the root, only a configure.in file. I do not know what needs to be done to compile version r475 of libmpcdec/musepack.
Question 1. Should I just compile mpd-minimal excluding this optional dependency?
The config.log for wavpack also had similar errors. I could post those errors here if you think it is worthwhile trying to figure this out. Alternatively, the TC4.x wavpack extension (it is version 4.60.0 while the one I was trying to compile was 4.70.0) could be copied to the TC5.x repo as it seems to work with mpd.
Question 2. Should I compile mpd-minimal with the TC4.x extension of wavpack?
-
I'd say yes and yes.
-
Well, I must confess.. my handy little submit script worked great on my PC however not so good on others is seems.. So I had to fix it, hopefully is now more friendly to other configurations and build directories. I believe the script can be run from most locations on a system , anyhow is updated
Also thanks to gavs for spotting an issue with submitqc5 extension, While I'm not the maintainer, this needed to be fixed and the real maintainer is AWOL at the moment, so I took the liberty of fixing it along with a few other minor improvements, submitted again..
-
I took one more try at compiling wavpack, in case I had made an error. Though the build process completed, it was not successfully detected during compilation of mpd. There was a message about iconv in the config.log for wavpack that may have something to do with this problem?
configure:13161: checking for iconv.h
configure:13161: result: yes
configure:13163: checking for iconv
configure:13179: gcc -o conftest -g -O2 conftest.c >&5
/tmp/ccmZ2X1n.o: In function `main':
/home/tc/wavpack-4.70.0/conftest.c:34: undefined reference to `libiconv_open'
/home/tc/wavpack-4.70.0/conftest.c:35: undefined reference to `libiconv'
collect2: error: ld returned 1 exit status
configure:13179: $? = 1
...
configure:13186: result: no
configure:13188: checking for iconv in -liconv
configure:13210: gcc -o conftest -g -O2 conftest.c -liconv >&5
configure:13210: $? = 0
configure:13212: result: yes
I did not know how to resolve this so I took juanito's advice and compiled mpd using wavpack from the TC4.x repo and leaving out libmpcdec. I will submit the mpd-minimal extension done this way.
I used the following extensions from the TC4.x repo:
libmpdclient.tcz
libmpdclient-dev.tcz
tcp_wrappers-dev.tcz (tcp_wrappers.tcz has already been copied over)
wavpack.tcz
wavpack-dev.tcz
These seemed to work during compilation of mpd and their respective features were turned on. I suppose they could be copied to the TC5.x repo?
Next, I will try to prepare gmpc, a client for mpd, to submit.
-
libmpdclient, libmpdclient-dev, tcp_wrappers-dev, wavpack and wavpack-dev copied to the tc-5.x repo.
Note that, as per the info file, wavpack was recompiled to remove the dep on libiconv, so I removed this from the dep file for tc-5.x.
glibc in tinycore provides iconv functions so libiconv should not be required - however if the extension is loaded, some applications will try to use it in preference to glibc, which, for the sake of less bloat, should be avoided.
-
Extensions libmpd, libmpd-dev, gmpc, gmpc-dev, gmpc-locale, gmpc-doc, gmpc-albumview, gmpc-tagedit and gmpc-tagedit-locale have been submitted.
Extensions libunique, libunique-dev, libunique-gir and mpd-minimal had been previously submitted.
Thank you all for your guidance in this project.
-
..and thanks for your contribution :)