X-Recipient:	archive-cygwin AT delorie DOT com
X-Spam-Check-By:	sourceware.org
Date:	Tue, 25 Jan 2011 16:50:53 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Bug in libiconv?
Message-ID:	<20110125155053.GA6353@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<20110124154158 DOT GA15279 AT calimero DOT vinschen DOT de> <4D3E3EF6 DOT 7010501 AT cwilson DOT fastmail DOT fm> <20110125111507 DOT GA28470 AT calimero DOT vinschen DOT de> <4D3EE67D DOT 3000900 AT cwilson DOT fastmail DOT fm>
MIME-Version:	1.0
In-Reply-To:	<4D3EE67D.3000900@cwilson.fastmail.fm>
User-Agent:	Mutt/1.5.21 (2010-09-15)
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

On Jan 25 10:04, Charles Wilson wrote:
> On 1/25/2011 6:15 AM, Corinna Vinschen wrote:
> > - Why on earth is libiconv on Cygwin using Windows functions in some
> >   places?
> > 
> >   - libcharset/lib/relocatable.c
> >   - srclib/progreloc.c
> >   - srclib/relocatable.c
> >   - lib/relocatable.c
> 
> whoo boy. That's...a long story. It's all part of Bruno's magic
> relocatability machinery.  However, on cygwin it should be using unixish
> mechanisms (at least for exe's -- looking at /proc/$pid/exe.  For
> DLLs...I think it needs to keep using the DllMain approach).

Really?  Why can't you use the same mechanism as on Linux?  The
find_shared_library_fullname() function examines /proc/self/maps, which
is also available on Cygwin.  This was already available on 1.5!

> > - libcharset/lib/relocatable.c and srclib/relocatable.c define their own
> >   DllMain and use Windows functions.  And the old
> >   cygwin_conv_to_posix_path function as well.
> 
> Well, yes.  It's how DLLs determine their installation path, so they can
> then automatically deduce the relative path to <whatever>.  And since
> that requires using a win32 function (GetModuleFileName) it needs to
> convert to cygwin format.

See above.

> > - Same file, function locale_charset() contains old Cygwin-specific
> >   code which is outdated.  AFAICS it shouldn't hurt, though, since
> >   Cygwin no longer returns "US-ASCII".
> > 
> > - lib/iconv_open1.h and lib/iconv.c exclude Cygwin from the usage of the
> >   ei_ucs2internal encoding table.  I'm not sure if that's right or
> >   wrong, but it looks worrying.
> 
> Well, remember (A) upstream libiconv itself hasn't been updated since
> 30-Jun-2009, which predated cygwin 1.7.1 (23 Dec 2009), and (B) even our
> most recent version (1.13.1-1) was released almost simultaneously (23
> Dec 2009) -- and there was a LOT of shakeup in all that stuff from 1.7.1
> thru 1.7.5.

I wasn't trying to blame you.  I was just trying to point out potential
problems which deserve a more POSIXy handling on Cygwin.

> > Please note that I defined
> > __STDC_ISO_10646__ for Cygwin 1.7.8 yesterday.  This define is
> > missing since 1.7.2.
> 
> Hmmm...maybe I should (re)build libiconv against a snapshot?

I think that should be safe.  There's most likely no new API which would
accidentally be pulled in by libiconv(*).


Corinna


(*) Famous last words...

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -