public inbox for gentoo-embedded@lists.gentoo.org
 help / color / mirror / Atom feed
* [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