Re: libiconv

[Marco Atzeri]

--- Gio 28/10/10, Eric Blake  ha scritto:

> 
> Did you install a self-built cygwin, including the newlib
> ,
> thus overwriting the real  that is included
> by installing the
> libiconv package?  If so, rerun setup.exe and
> reinstall libiconv.
> 
> It's a known issue that installing a self-built cygwin
> version installs
> too many files, including clobbering  when
> it shouldn't.
> 
> -- 
> Eric blake   ebl...@redhat.com 


Thanks, 
I am using a cygwin built from cvs. I never noticed before
the iconv.h overlapping


Marco





--
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

Re: libiconv

[Samuel Thibault]

Marco Atzeri, le Thu 28 Oct 2010 18:28:27 +0100, a écrit :
> it is already there
> 
> and /usr/include/iconv.h seems to not include 
> libiconv*  function but only iconv* ones

Is this really cygwin's /usr/include/iconv.h?

Samuel

--
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

Re: libiconv

[Eric Blake]

On 10/28/2010 11:28 AM, Marco Atzeri wrote:
> --- Gio 28/10/10, Samuel Thibault  ha scritto:
> 
>> Marco Atzeri, le Thu 28 Oct 2010
>> 18:08:18 +0100, a écrit :
>>> is the additional "lib" correct ?
>>
>> Yes. You need to #include  to get the proper
>> refname.
>>
>> Samuel
>>
> 
> Hi Samuel,
> #include 
> 
> it is already there
> 
> and /usr/include/iconv.h seems to not include 
> libiconv*  function but only iconv* ones

Did you install a self-built cygwin, including the newlib ,
thus overwriting the real  that is included by installing the
libiconv package?  If so, rerun setup.exe and reinstall libiconv.

It's a known issue that installing a self-built cygwin version installs
too many files, including clobbering  when it shouldn't.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: libiconv

[Marco Atzeri]

--- Gio 28/10/10, Samuel Thibault  ha scritto:

> Marco Atzeri, le Thu 28 Oct 2010
> 18:08:18 +0100, a écrit :
> > is the additional "lib" correct ?
> 
> Yes. You need to #include  to get the proper
> refname.
> 
> Samuel
> 

Hi Samuel,
#include 

it is already there

and /usr/include/iconv.h seems to not include 
libiconv*  function but only iconv* ones

---
#ifndef _ICONV_H_
#define _ICONV_H_

#include <_ansi.h>
#include 
#include 
#include 

/* iconv_t: charset conversion descriptor type */
typedef _iconv_t iconv_t;

_BEGIN_STD_C

#ifndef _REENT_ONLY
iconv_t
_EXFUN(iconv_open, (_CONST char *, _CONST char *));

size_t
_EXFUN(iconv, (iconv_t, char **, size_t *, char **, size_t *));

int
_EXFUN(iconv_close, (iconv_t));
#endif

iconv_t
_EXFUN(_iconv_open_r, (struct _reent *, _CONST char *, _CONST char *));

size_t
_EXFUN(_iconv_r, (struct _reent *, iconv_t, _CONST char **,
  size_t *, char **, size_t *));

int
_EXFUN(_iconv_close_r, (struct _reent *, iconv_t));

_END_STD_C

#endif /* #ifndef _ICONV_H_ */


Marco





--
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

Re: libiconv

[Samuel Thibault]

Marco Atzeri, le Thu 28 Oct 2010 18:08:18 +0100, a écrit :
> is the additional "lib" correct ?

Yes. You need to #include  to get the proper refname.

Samuel

--
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

Re: libiconv and iconv() prototype

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Charles Wilson on 12/22/2009 8:25 PM:
> Err...by changing the prototype, doesn't that change the ABI?
> 
> -_EXFUN(iconv, (iconv_t, _CONST char **, size_t *, char **, size_t *));
> +_EXFUN(iconv, (iconv_t, char **, size_t *, char **, size_t *));

On the binary-compatibility perspective: I see no problem.  const char**
and char** are the same size, so older applications calling the newer
function will still function as if nothing had changed.   And as long as
the implementation doesn't modify the argument (which libiconv does not,
otherwise libiconv wouldn't have worked even when the const is present),
all that is lost by omitting the const is an opportunity for a compiler
optimization.  You are correct that the POSIX prototype is not
const-correct, since no sane implementation will ever modify the contents
of inbuf.  But it is specified without the const in POSIX iconv pre-dated
const-correctness issues.

On the compilation-compatibility perspective: yes, this is a
backwards-incompatible change - anyone that passed a const char** to iconv
will now have to add a cast to silence a compiler warning.  On the other
hand, such code was already non-portable because it conflicts with the
POSIX prototype, so adding the cast to such code is good for portability
anyways.

> So, are you advocating a new cygiconv-3.dll?  Or am I wrong, and this
> change does NOT affect the ABI?

I don't see any reason to bump to cygiconv-3.dll - it seems like keeping
things at cygiconv-2.dll should still work.

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksxp+QACgkQ84KuGfSFAYDDqgCgzLreqAg20Hx7ml0ZucjKdn9V
7hoAmQEae3eNyYxl2RC9OMKrt9TV5vvC
=UsST
-END PGP SIGNATURE-

--
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

Re: libiconv and iconv() prototype

[Charles Wilson]

Eric Blake wrote:
> The newlib header for iconv.h was recently fixed to comply with the POSIX 
> prototype, but cygwin is still stuck with a bogus const on the second 
> argument 
> of iconv().  It's kind of a catch-22 - libiconv configures itself to preserve 
> the system's prototype, but on cygwin, the system's prototype comes from 
> libiconv, because we do not use newlib's implementation.  So it takes an 
> explicit action while building from source in order to properly get a 
> libiconv 
> installation to use the correct signature; I think it should be possible with:
>  ./configure am_cv_proto_iconv_arg1=
> 
> Any chance we can get a new libiconv-1.13-11 build with the updated signature?

Err...by changing the prototype, doesn't that change the ABI?

-_EXFUN(iconv, (iconv_t, _CONST char **, size_t *, char **, size_t *));
+_EXFUN(iconv, (iconv_t, char **, size_t *, char **, size_t *));

So, are you advocating a new cygiconv-3.dll?  Or am I wrong, and this
change does NOT affect the ABI?

I don't object, if so -- POSIX compliance is a good thing. But I just
want to be sure what I'm jumping into, first.

--
Chuck



--
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

Re: libiconv and iconv() prototype

[Eric Blake]

Eric Blake  byu.net> writes:

> I think it should be possible with:
>  ./configure am_cv_proto_iconv_arg1=

Nope, not quite enough.  It needs the hairier:

 ./configure am_cv_proto_iconv_arg1= am_cv_proto_iconv="extern size_t iconv 
(iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t 
*outbytesleft);"

-- 
Eric Blake



--
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

Re: libiconv on WinXP Cygwin

[Max Bowsher]

Jamil Alkadir wrote:
> I am now trying to compile libiconv-1.9.1

Why not use the pre-existing libiconv-1.9.1 cygwin package, as installable from 
setup.exe?


> /usr/bin/install: cannot remove `/usr/lib/../bin/cygiconv-2.dll': Permission
> denied

/usr/bin/install uses the libiconv DLL, hence when install is running, the DLL is in 
use and cannot be overwritten.


Max.


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

Re: libiconv TSCII

[Gerrit P. Haase]

Hallo Peter,

Am Samstag, 18. Oktober 2003 um 14:58 schriebst du:

> Dear All,

> I didn't find a libiconv specific mailing list, and googling around
> suggested, that libiconv is occasionally discussed here (If anybody
> has info about a  libiconv specific  mailing list, I would be more
> than glad to learn about it).

http://www.gnu.org/directory/localization/libiconv.html


Gerrit
-- 
=^..^=


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

Re: libiconv package must be recompiled

[Charles Wilson]

Sam Steingold wrote:

I'm sorry, but while I have no objection to rebuilding the package per
se, I need more than "stir in this magic powder and it works!" before
I'm entirely comfortable with this.


as  explains,
the apparent problem is that EILSEQ was conflated with ENOENT.
I.e., both were defined to be the same number, which caused CLISP to
barf on innocuous errors.
Ok, I misunderstood the original report -- I thought the problem was 
*solely* a cygwin kernel error.  But, because EILSEQ/ENOENT are 
#defines, even after cygwin gets fixed, the compiled libiconv stays 
broken.   libiconv was returning an EILSEQ error -- but because cygwin 
*at the time libiconv was compiled* defined EILSEQ == ENOENT, clisp was 
getting confused.  So by recompiling libiconv against a newer cygwin 
that correctly defines EILSEQ, libiconv will return the correct error 
code and clisp will stop being confused.

Got it.

Look for a new release of libiconv soon.

--Chuck

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

Re: libiconv package must be recompiled

[Charles Wilson]

Sam Steingold wrote:

The following message is a courtesy copy of an article
that has been posted to gmane.os.cygwin as well.
It appears that the current cygwin libiconv package still has problems
described in the following messages:


it also appears that all it takes to fix the problem is to
recompile the libraries from the current sources.
Charles, are you the maintainer of the cygwin package?
If yes, could you please remake the package?
If no, could you please ask the maintainer to do that?
Sorry for the delay in responding; gmane web access was down and I 
couldn't review the messages you reference above until today.

It seems odd that simply recompiling libiconv/libcharset will "fix" this 
problem (whatever it is).  Is there any explanation for WHY this "fixes" 
the problem (I'd hate to actually be *hiding* the problem, instead of 
fixing it -- which is fairly likely, if we don't know what's really 
going on...)

What's the problem?  A missing export?  The fact that I'd now be using a 
fancy new binutils (the existing libiconv package was built a year ago, 
and there have been a few binutils releases since then).

Or worse -- somehow we've tickled an incompatibility between DLLs built 
with "old" ld and apps built with "new" ld?

I'm sorry, but while I have no objection to rebuilding the package per 
se, I need more than "stir in this magic powder and it works!" before 
I'm entirely comfortable with this.

--Chuck



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

RE: libiconv

[Robert Collins]

> -Original Message-
> From: Gerrit P. Haase [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, May 02, 2002 9:16 AM

> 
> Come on Charles,
> 
> you have a complete version of libiconv, ready for upload,
> what should the volunteer do?  Repackage it to install in
> /usr instead of /usr/local ?

Maintenance takes time. If Chuck is running out of time, that's his
call.

Rob

P.S. Chuck, please don't go!


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/