Tiny Core Linux
Tiny Core Extensions => TCE Q&A Forum => Topic started by: mikshaw on December 06, 2008, 10:24:25 PM
-
This thread is probably not important...just a couple of things I noticed....
glib2-devs is nearly twice the size of glib2. I find that bizarre, considering most dev packages are much smaller than the runtime packages.
Isthe glib2-locales package a necessity, or is it just if you don't speak US English? In other words, if I compile something using glib2-devs without specifying --disable-nls or similar, do you think I'm going to need the locales at runtime?
The gtk2 info says glib 2.16.4 is needed, but the only glib package I see is 2.16.6. I assume as long as it's equal to or newer than 2.16.4 it will work?
-
It very much varies on the size relationship between the main package size and the devs size. So far they seem to mostly comparable. Sometimes there is a large -devs extension and a small main one, but that is not the norm.
I normally split the -locales from extensions to save size, but I like to make them available if folks need them. Tiny is the default, but I don't like to discard parts of packages since some will want them. Locales are for those who want other languages like Spanish from what I understand. I have never really used them since I don't use other languages. So they are not normally needed. I am not sure how it would work if you build a package with the -locales installed from glib and do not use --disable-nls and then later do not run with the glib -locales loaded, but I don't think the app itself would fail to run.
I will change the info file of gtk2 as glib was upgraded. When I rebuilt gtk2 I used the upgraded glib-2.6.16, but glib-2.6.16 would work fine for a gtk built with glib-2.6.14. So yes, using upgraded libraries for apps or libs built on older libraries works as long as the major version has not changed in virtually any case.
-
Thanks. I believe that clears it all up for me.
-
Just noticed there is no glib-config in the glib2-dev package (needed to compile mc). Should it be included in that package, or is it part of something else?
-
I thought glib-config was only for glib1 - glib2 is pkgconfig, no?
BTW - weren't we going to set PKG_CONFIG_PATH to /usr/lib/pkgconfig:/usr/local/lib/pkgconfig as a default?
-
It seems to have been removed a while ago: http://lists.freedesktop.org/archives/pkg-config/2005-December/000066.html
But just setting PKG_CONFIG_PATH should be good enough in most cases.
BTW - weren't we going to set PKG_CONFIG_PATH to /usr/lib/pkgconfig:/usr/local/lib/pkgconfig as a default?
Yes, I voted for that since the main TC prefix is /usr/local after all (think I posted a config step somewhere as well...)
-
Apparently mc 4.6 wants both pkg-config and glib-config:
configure:3795: checking for pkg-config
configure:3813: found /usr/bin/pkg-config
configure:3826: result: /usr/bin/pkg-config
configure:3843: checking for glib-2.0
configure:3894: checking for glib-config
configure:3927: result: no
configure:3894: checking for glib12-config
configure:3927: result: no
configure:3987: checking for glib-config
configure:4018: result: no
configure:4026: checking for GLIB - version >= 1.2.6
configure:4160: result: no
configure:4246: error: Test for glib failed.
GNU Midnight Commander requires glib 1.2.6 or above
I just downloaded a newer snapshot which was created after the pkg-config change (mc stable is from 2005), so maybe that one will work.
-
unfortunately it still wants glib-config =oppp
I installed emelfm, which isn't as great for me, but will do for now.
-
I have a build script for midnight commander that is on my old usb drive at home, but I forgot the dependencies and other things such as configure flags. I can make an extension next week sometime once I am back in town and can see what was involved.
-
Mik, it wants glib1 (1.2.6 or above doesn't include glib2) :)
-
According to the readme, it looks for Glib2 first and then Glib1.2. You can force it to use Glib1.2 as a configure option, but I was trying not to have both versions installed.
Maybe I'll do that anyway, since I decided to go with a hybrid system. On that off-topic subject, what happens if you try to have home=hda4 and local=hda4?
It appears as though home will fail if hda4 is already mounted for tclocal:
303 if [ -n "$MYHOME" ]; then
304 wait $fstab_pid
305 mount /mnt/"$MYHOME"
306 if [ "$?" == 0 ]; then
307 if [ -d "/mnt/$MYHOME$HOME" ]; then
308 mount --bind "/mnt/$MYHOME$HOME" "$HOME/"
309 else
310 mkdir -p "/mnt/$MYHOME$HOME"
311 mount --bind "/mnt/$MYHOME$HOME" "$HOME/"
312 tar -C /etc/skel -cf - . | tar -C "$HOME" -xf -
313 printf 'wm: %s\nicons: %s\n' "$DESKTOP" "$ICONS" > "$HOME"/.desktop
314 chown -Rh "$USER".staff "$HOME"
315 fi
316 fi
317 else
318 tar -C /etc/skel -cf - . | tar -C "$HOME" -xf -
319 printf 'wm: %s\nicons: %s\n' "$DESKTOP" "$ICONS" > "$HOME"/.desktop
320 chown -Rh "$USER".staff "$HOME"
321 chmod g+s "$HOME"
322 fi
If hda4 is already mounted, the return of line 305 won't be 0, and so persistent home won't be used. At least that's what it looks like to me, so I plan to put "mount --bind /mnt/hda4/tclocal /usr/local" in bootlocal.sh and use only home=hda4. Haven't tested it yet until I add the reiserfs module into the base.
-
Perhaps a better change would be:
...
mountpoint /mnt/"$MYHOME" || mount /mnt/"$MYHOME"
if [....
so it would check for a mountpoint first, and only then try to mount.
-
I got it installed using glib1.2, thanks. Now having problems getting subshells working, and it's apparently a different issue than what I had in DSL...but that's for another day. Now I have to figure out why the reiserfs module isn't being loaded =op