From: Ed W <lists@wildgooses.com>
To: gentoo-embedded@lists.gentoo.org
Subject: Re: [gentoo-embedded] ref bug 297229 (virutal/libiconv vs sys-libs/uclibc[iconv] vs sys-devel/gcc)
Date: Fri, 04 Jun 2010 12:44:36 +0100 [thread overview]
Message-ID: <4C08E724.3080605@wildgooses.com> (raw)
In-Reply-To: <1275606120.2949.3.camel@hangover>
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
next prev parent reply other threads:[~2010-06-04 12:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2010-06-04 15:56 ` Peter Stuge
2010-06-04 23:20 ` solar
2010-06-07 10:20 ` Ed W
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C08E724.3080605@wildgooses.com \
--to=lists@wildgooses.com \
--cc=gentoo-embedded@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox