On a uClibc host glib2 will will not compile. nls is not really
supported so we are able to build a much lighter weight glib2. I will
attach patches that provide the stubs and make the configure check non
fatal that will allow us to make use of glib2 without the need to
gettext or the masked libiconv. patches are provided by psm and myself.
initial testing was done on the embedded mailing list.
Created attachment 49965 [details, diff]
moves ppc-macos glibtoolize into src_unpack and does patching etc..
Created attachment 49966 [details, diff]
adds stubs to gconvert.c
Created attachment 49967 [details, diff]
makes configure non fatal and uses internal stubs
getext is still being used in this version. <=2.4.8 work here.. I hack to hack on it some more todo 2.6.1
I got 2.6.1 to compile but I had to use really ulgy hacks to work around gettext.
For now I've put <dev-libs/glib-2.5 in the $PORTDIR/profiles/packages and will attach the 2.4.8 patches and get somebody to confirm they work for them without
Created attachment 50027 [details, diff]
what do you intend to do with it ? I don't think eg. pango & gtk will work very well without a functioning g_convert_* and glib functionality based on it.
g_convert should return everything in english.
As it stands now glib2 is a dep on quite a few things.
Users interested in building console apps such as irssi/mc/splashd/etc are unable todo so without this patch.
Misc people have been using the patch for about 2-3 months.
As far as I know iggy the the only one who dove into a complete X windowing system. No idea if he used gtk or not.
If the interface --without-gettext --disable-nls --libiconv=no worked this would not be needed.
Created attachment 50138 [details, diff]
updated ebuild diff to use myconf.
i talked to iggy yesterday on IRC, not sure if you picked up that conversation. According to him it does not work (not even with irssi) and that seems logical to me, because afaics the strings should now return NULL and error if any of these functions are used.
I don't see this as a healthy solution, it might work on some apps that do not use these functions at all, but those are rare & glib to some extent uses this functionality as well internal.
Created attachment 50145 [details, diff]
allows to build glib-2.6 w/o gettext
foser: that's odd cuz I built and tested irssi v0.8.9 and mc.
ldd `which irssi`
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x2777d000)
libdl.so.0 => /lib/libdl.so.0 (0x27782000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x27786000)
libncurses.so.5 => /lib/libncurses.so.5 (0x27802000)
libc.so.0 => /lib/libc.so.0 (0x27842000)
ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x27773000)
[ebuild R ] app-misc/mc-4.6.0-r12 -X -debug -gpm +ncurses (-nls) -samba -slang -unicode
ldd `which mc`
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x26102000)
libncurses.so.5 => /lib/libncurses.so.5 (0x2617e000)
libext2fs.so.2 => /lib/libext2fs.so.2 (0x261be000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x261d8000)
libc.so.0 => /lib/libc.so.0 (0x261dc000)
ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x260f8000)
For now all we can do is ask for more testing cuz when iconv_open() returns (-1)no conversion is supposed to take place.
perhaps we should set errno = EINVAL;
Initial code is based on what the masked libiconv does.
Peter, thanks that patch for 2.6.1 worked around the problem cleanly
I can't understand why it shouldn't work for iggy/foser.
I can use mc, I have built gtk+, the only unusual, but expected behaviour is
that a conversion from UTF8 to ASCII fails (saying not supported)
>iggy< CTCP VERSION
-iggy- VERSION irssi v0.8.10-rc5
This version is not in portage yet, it uses g_convert contrary to any version in portage. That is why you don't see it (yet) with irssi.
gtk/pango etc. might work to some extent as long as you don't deal with files & have utf8 po files, etc. i guess.
I do not doubt it works in some cases, but I do not think this is wise to apply gentoo wide. The proper solution to me seems ditching gconvert.h in this case, because then you will get a reasonable indication of when something will or will not work reliable. But I wouldn't want to support that in the tree either.
Something that seems more viable to me is having a local copy of iconv or something, but I have no real idea on what you want to achieve here anyway.
Confirmed the problems that foser mentions for the g_convert() Another solution will be found for the iconv() problems. The nls handling is good.
Ok foser this bug has been appears to have been stalled for quite a bit of time.
Are you going to add the slimed down patch from comment #11 which corrects a bug in glib?
http://bugs.gnome.org/show_bug.cgi?id=135899 , here's the bug where it got removed.
It seems to me including gi18n.h means you got to have gettext, since glib itself uses it for goption you can't get around it.
nevermind foser. you clearly don't understand whats going on. I'll fix it.
I know what is going on, your attitude and wishes get in the way of stable development. So no, at this point, this 'patch' shouldn't be added. The iconv patch breaks stuff, the NLS patch breaks stuff. Your condescending attitude doesn't change that.
sigh. I already stated the iconv() patch and the g_convert() behavior showed up in
The NLS patch works around the already broken code.
So that leaves me with a few options
1) do nothing
2) do something
If my plan was #1 I would have not opened a bug in the first place.
I'm seeing somebody else has some simular problems building glib, and the developers response was this:
> I have read the Makefile there, only to find they use a
> "--with-libiconv=gnu" configure argument. I don't know why theirs can
> succeed, while my "--with-libiconv=/usr/local" can't help pass the
> configuration step. :(
Because the allowed values of the --with-libiconv flag limit it. Output
from `./configure --help`:
use the libiconv library
So it is supposed to be possible to disable iconv usage from configure with the vanilla source.
the gettext patch is not applied for the following reasons :
a) it breaks things (comment #18)
b) just applying it like suggested has no impact at all
c) there has been no reasons given why we should add this patch while upstream
clearly has chosen to remove this functionality