Hi, replying here rather than on the bug tracker, but please set me
straight if it's better discussed elsewhere?



(In reply to comment #11 - Diego)
> The problem is not build, the problem is that if libiconv is removed
_after_

> gcc is merged… it breaks.
>

I have seen you and others note this several times (and the reason why
seems clear), however, what I don't get is why this is any different to
the normal situation with glibc?


Q: Why would libiconv ever be uninstalled/removed?

Q: After installing libiconv and rebuilding gettext/gcc, the upgrade
process to a new libiconv presumably then becomes, 1) upgrade libiconv,
2) rebuild gettext/gcc, 3) delete old libiconv libraries? Sounds bearable?


Is the problem that under glibc there is no dependency created at all
with regards to iconv, but if libiconv is floating around then there is
a dep created? And subsequently it's "hard" to avoid recompiles of gcc
picking up libiconv, hence ever removing that dependency?


Is this basically the same issue with gettext on uclibc?

I guess the real question here is what's the best way to build glib
under uclibc? Recommendations please?


Thanks

Ed W

On Thu, 2010-06-03 at 11:42 +0100, Ed W wrote:
[snip]

> I guess the real question here is what's the best way to build glib
> under uclibc? Recommendations please?
>


mini-iconv.c or fake it.


+#ifndef HAVE_ICONV_H
+typedef void *iconv_t;
+
+static iconv_t iconv_open(const char *tocode, const char *fromcode)
+{
+ return (iconv_t)(-1);
+}
+
+static int iconv_close(iconv_t cd)
+{
+ free(cd);
+
+ return 0;
+}
+
+static size_t iconv() {return 0;}
+#endif



--
Ned Ludd <solar@gentoo.org>
Gentoo Linux

On 04/06/2010 00:02, Ned Ludd wrote:

On Thu, 2010-06-03 at 11:42 +0100, Ed W wrote:
[snip]



I guess the real question here is what's the best way to build glib
under uclibc? Recommendations please?




mini-iconv.c


Do you have a recipe for this? I have built a couple of things using
mini-iconv.c now and it seems often to need a bit of hacking of config
files more than anything else. I don't recall exactly what came up with
glib, but it seemed like a much harder problem - from memory I believe
it also had a required dependency on gettext that seemed unavoidable? (I
gave up at that point I think?)




or fake it.



See now, I'm still missing the bigger picture here. I'm still not sure
I understand why I don't just do this "properly" and either use iconv in
uclibc or libiconv (and gettext)? Is there anything "bad" in having
libiconv installed other than it becoming an accidently gcc dep? (And is
that an unmanageable situation?)


From the point of view of an ignoramous this seems like a real battle
to avoid that which has bearable consequences to just give in and go
with the flow? I must be missing something important though - how/where
is this going to bite me in the future? I would like to try and figure
this out now rather than suffer pain later...


Thanks

Ed W

Ed W wrote:
> I'm still not sure I understand why I don't just do this "properly"
> and either use iconv in uclibc or libiconv (and gettext)?

Is it big? Is it neccessary? Usually it's a high priority to take
away every last thing that is not absolutely neccessary.


//Peter

On Fri, 2010-06-04 at 12:44 +0100, Ed W wrote:
> On 04/06/2010 00:02, Ned Ludd wrote:
> > On Thu, 2010-06-03 at 11:42 +0100, Ed W wrote:
> > [snip]
> >
> >
> >> I guess the real question here is what's the best way to build glib
> >> under uclibc? Recommendations please?
> >>
> >>
> >
> > mini-iconv.c
>
> Do you have a recipe for this? I have built a couple of things using
> mini-iconv.c now and it seems often to need a bit of hacking of config
> files more than anything else. I don't recall exactly what came up with
> glib, but it seemed like a much harder problem - from memory I believe
> it also had a required dependency on gettext that seemed unavoidable? (I
> gave up at that point I think?)
>
>
> > or fake it.
> >
>
> See now, I'm still missing the bigger picture here. I'm still not sure
> I understand why I don't just do this "properly" and either use iconv in
> uclibc or libiconv (and gettext)? Is there anything "bad" in having
> libiconv installed other than it becoming an accidently gcc dep? (And is
> that an unmanageable situation?)


I avoid gettext 100% in my uClibc env by using the following stub
macros.


uClibc env.d # cat /usr/include/libintl.h
#ifndef _LIBINTL_H
#define _LIBINTL_H 1

#include <features.h>

#if defined(__UCLIBC__) && !defined(__UCLIBC_HAS_GETTEXT_AWARENESS__)
/* Stubs for gettext/locale bullshit... */
#undef gettext
#undef dgettext
#undef dcgettext
#undef ngettext
#undef dngettext
#undef dcngettext
#undef textdomain
#undef bindtextdomain
#undef bind_textdomain_codeset
/* this fucker seems to be installed in /usr/include/locale.h */
/* #undef setlocale */
#undef _
#undef N_

#define gettext(String) (String)
#define dgettext(Domain, String) (String)
#define dcgettext(Domain, String, Type) (String)
#define ngettext(Singular, Plural, Count) ((Count) == 1 ? (const char *)
(Singular) : (const char *) (Plural))
#define dngettext(Domain, Singular, Plural, Count) ((Count) == 1 ?
(const char *) (Singular) : (const char *) (Plural))
#define dcngettext(Domain, Singular, Plural, Count, Category) ((Count)
== 1 ? (const char *) (Singular) : (const char *) (Plural))
#define dgettext(Domain, String) (String)
#define dcgettext(Domain, String, Type) (String)

#ifndef _LOCALE_H
/* #define setlocale(Category, Locale) ((char *)NULL) */
#endif

#define bindtextdomain(Domain, Directory) (Domain)
#define bind_textdomain_codeset(Domain, Codeset)
#define textdomain(String)

#define _(String) (String)
#define N_(String) (String)

#endif /* GETTEXT */
#endif /* _LIBINTL_H */

I avoid gettext 100% in my uClibc env by using the following stub
macros.



Ohh. Cool!

I'm only eyeballing it, not tried it on anything yet, but can you
confirm this lets you build glib?? (Much extra makefile hacking needed?)
If so then this is very useful - thanks for sharing



Ed W