* [gentoo-embedded] ref bug 297229 (virutal/libiconv vs sys-libs/uclibc[iconv] vs sys-devel/gcc) @ 2010-06-03 10:42 Ed W 2010-06-03 23:02 ` Ned Ludd 0 siblings, 1 reply; 6+ messages in thread From: Ed W @ 2010-06-03 10:42 UTC (permalink / raw To: gentoo-embedded; +Cc: flameeyes 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-embedded] ref bug 297229 (virutal/libiconv vs sys-libs/uclibc[iconv] vs sys-devel/gcc) 2010-06-03 10:42 [gentoo-embedded] ref bug 297229 (virutal/libiconv vs sys-libs/uclibc[iconv] vs sys-devel/gcc) Ed W @ 2010-06-03 23:02 ` Ned Ludd 2010-06-04 11:44 ` Ed W 0 siblings, 1 reply; 6+ messages in thread From: Ned Ludd @ 2010-06-03 23:02 UTC (permalink / raw To: gentoo-embedded; +Cc: flameeyes 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-embedded] ref bug 297229 (virutal/libiconv vs sys-libs/uclibc[iconv] vs sys-devel/gcc) 2010-06-03 23:02 ` Ned Ludd @ 2010-06-04 11:44 ` Ed W 2010-06-04 15:56 ` Peter Stuge 2010-06-04 23:20 ` solar 0 siblings, 2 replies; 6+ messages in thread From: Ed W @ 2010-06-04 11:44 UTC (permalink / raw To: gentoo-embedded 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-embedded] ref bug 297229 (virutal/libiconv vs sys-libs/uclibc[iconv] vs sys-devel/gcc) 2010-06-04 11:44 ` Ed W @ 2010-06-04 15:56 ` Peter Stuge 2010-06-04 23:20 ` solar 1 sibling, 0 replies; 6+ messages in thread From: Peter Stuge @ 2010-06-04 15:56 UTC (permalink / raw To: gentoo-embedded 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-embedded] ref bug 297229 (virutal/libiconv vs sys-libs/uclibc[iconv] vs sys-devel/gcc) 2010-06-04 11:44 ` Ed W 2010-06-04 15:56 ` Peter Stuge @ 2010-06-04 23:20 ` solar 2010-06-07 10:20 ` Ed W 1 sibling, 1 reply; 6+ messages in thread From: solar @ 2010-06-04 23:20 UTC (permalink / raw To: gentoo-embedded 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 */ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-embedded] ref bug 297229 (virutal/libiconv vs sys-libs/uclibc[iconv] vs sys-devel/gcc) 2010-06-04 23:20 ` solar @ 2010-06-07 10:20 ` Ed W 0 siblings, 0 replies; 6+ messages in thread From: Ed W @ 2010-06-07 10:20 UTC (permalink / raw To: gentoo-embedded > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-06-07 11:05 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-06-03 10:42 [gentoo-embedded] ref bug 297229 (virutal/libiconv vs sys-libs/uclibc[iconv] vs sys-devel/gcc) Ed W 2010-06-03 23:02 ` Ned Ludd 2010-06-04 11:44 ` Ed W 2010-06-04 15:56 ` Peter Stuge 2010-06-04 23:20 ` solar 2010-06-07 10:20 ` Ed W
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox