Version 1.17-1 of "libiconv" has been uploaded as test:
- libiconv-1.17-1
- libiconv2-1.17-1
- libcharset1-1.17-1
- libiconv-devel-1.17-1
Please, report any issues.
--
GNU LIBICONV - character set conversion library
This library provides an iconv() implementation, for use on sys
Version 1.16-2 of "libiconv" has been promoted to current.
- libiconv-1.16-2.tar.xz
- libiconv2-1.16-2.tar.xz
- libcharset1-1.16-2.tar.xz
- libiconv-devel-1.16-2.tar.xz
The following files are packaged again, since they are necessary [1]:
- usr/lib/libcharset.a
- usr/lib/libiconv.a
Version 1.16-2 of "libiconv" has been uploaded as test:
- libiconv-1.16-2.tar.xz
- libiconv2-1.16-2.tar.xz
- libcharset1-1.16-2.tar.xz
- libiconv-devel-1.16-2.tar.xz
These files are packaged again, since they are necessary [1]:
- usr/lib/libcharset.a
- usr/lib/libiconv.a
which are
Version 1.16-1 of "libiconv" has been uploaded as test:
- libiconv-1.16-1.tar.xz
- libiconv2-1.16-1.tar.xz
- libcharset1-1.16-1.tar.xz
- libiconv-devel-1.16-1.tar.xz
These files are not packaged:
- usr/lib/libcharset.a
- usr/lib/libiconv.a
which are in libiconv-de
a dependency libiconv-devel in its "requires"
> attribute of the package-version-release.hint (I did not found the
> actual hint file when looking at the package list[1]) and likely also
> include the necessary options in the shipped pkg-config file.
Thanks; fixed in git, and
/include/libxml2/libxml/encoding.h:28:10: fatal error: iconv.h: No
such file or directory
#include
^
As libxml2-devel provides a header that has a hard dependency on iconv.h
it should also include a dependency libiconv-devel in its "requires"
attribute of the packa
The following packages have been updated in the Cygwin distribution:
* libiconv-1.14-3
* libiconv2-1.14-3
* libcharset1-1.14-3
* libiconv-devel-1.14-3
This library provides an iconv() implementation, for use on systems
which don't have one in their C standard library, or whose
implement
The following packages have been updated in the Cygwin distribution:
* libiconv-1.14-2
* libiconv2-1.14-2
* libcharset1-1.14-2
* libiconv-devel-1.14-2
This library provides an iconv() implementation, for use on systems
which don't have one in their C standard library, or whose
implement
On Wed, Aug 29, 2012 at 1:23 AM, Tasos Laskos wrote:
> One question though. how do you run a Linux command from Windows?
> I tried C:\cygwin\bin\bash.exe -c "ls -la" but it doesn't work in Cygwin.
>
You could just run
C:\cygwin\bin\ls -la
or, if C:\cygwin\bin is in the PATH, simply run
ls -la
package authors about the bump in the
configure process you're noticing.
Well, I guess depending on libiconv isn't that bad since it's pretty
much universally installed.
I'll give another shot to sorting this out but if I don't it's not the
end of the world.
Thanks
figure process you're noticing.
Well, I guess depending on libiconv isn't that bad since it's pretty
much universally installed.
I'll give another shot to sorting this out but if I don't it's not the
end of the world.
Thanks for the help Larry.
-
dependencies.
It's meant to create a self-contained package, so I don't want to rely on
what's already on the system.
I've attached the libiconv logfile and the cygcheck output.
OK, that explains the difference you and I are seeing. In your configure
output, you get:
che
f-contained package, so I don't want to rely on
what's already on the system.
I've attached the libiconv logfile and the cygcheck output.
OK, that explains the difference you and I are seeing. In your configure
output, you get:
checking for iconv... (cached) no, consider ins
n
what's already on the system.
I've attached the libiconv logfile and the cygcheck output.
OK, that explains the difference you and I are seeing. In your configure
output, you get:
checking for iconv... (cached) no, consider installing GNU libiconv
I don't see this because I
erimental/external/scripts/build.sh
bash build.sh
It fails when it tries to build the first dependency, libiconv, but I'm not
sure why.
For some reason it looks for a /usr/lib/libiconv.la while it has been
configured with a different prefix.
Anyone have any idea
erimental/external/scripts/build.sh
bash build.sh
It fails when it tries to build the first dependency, libiconv, but I'm
not sure why.
For some reason it looks for a /usr/lib/libiconv.la while it has been
configured with a different prefix.
Anyone have any ideas
nal/scripts/build.sh
bash build.sh
It fails when it tries to build the first dependency, libiconv, but I'm
not sure why.
For some reason it looks for a /usr/lib/libiconv.la while it has been
configured with a different prefix.
Anyone have any ideas?
Regards,
Tasos L.
[1] Arachni
libiconv was not included when I selected gcj in setup.exe:
$ gcj Test.java
/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld:
cannot find /usr/lib/libiconv.dll.a: No such file or directory
collect2: ld:n paluuarvo oli 1
I had to select libiconv manually myself in setup.exe
> On Sun, Oct 16, 2011 at 02:20:31PM -0400, Charles Wilson wrote:
> >The GNU libiconv package provides an iconv() implementation, for use on
> >systems which don't have one, or whose implementation cannot convert
> >from/to Unicode.
>
> Can we get a gold star for
On Sun, Oct 16, 2011 at 02:20:31PM -0400, Charles Wilson wrote:
>The GNU libiconv package provides an iconv() implementation, for use on
>systems which don't have one, or whose implementation cannot convert
>from/to Unicode.
Can we get a gold star for Chuck here? Supporting libic
The GNU libiconv package provides an iconv() implementation, for use on
systems which don't have one, or whose implementation cannot convert
from/to Unicode.
Routine update.
[[ compiled using gcc-4.5.3-2 ]]
Changes since libiconv-1.14-1
* Built usin
The GNU libiconv package provides an iconv() implementation, for use on
systems which don't have one, or whose implementation cannot convert
from/to Unicode.
[[ compiled using gcc-4.3.4-4 ]]
Changes since libiconv-1.13.1-2
o Update to latest ups
ncerning different approaches to dealing with 16bit wchar_t.
Subsequently, a bunch of new functions have been added to gnulib, and a
new type (wwchar_t); my assumption is future libiconv will use these new
functions and type on cygwin...
But (a) I don't want to wait for libiconv-1.14, and (b) I
On Fri, 2011-01-28 at 13:08 -0500, Charles Wilson wrote:
> Well, the library components appear to operate correctly. However, the
> executable, iconv.exe, does not do so. It picked up an dependency on a
> new symbol, _feinitialize, by being compiled against the 1.7.8.
>
> So, consider this versi
ers as well. It will be empty by
> default as well. The supported codesets are documented in
> http://cygwin.com/cygwin-ug-net/setup-locale.html#setup-locale-charsetlist
> If some weird alias is required, the user can add it to charset.alias.
> That's the optimal solution.
FWI
Thank you for filing a new bug report with GNU.
This is an automatically generated reply to let you know your message
has been received.
Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.
Your message has be
Hi Bruno,
On Feb 2 19:58, Bruno Haible wrote:
> [resent to the cygwin list; please add bug-gnu-libiconv to your replies]
Done.
> Hi Corinna,
>
> Thanks for your reply <http://cygwin.com/ml/cygwin/2011-01/msg00410.html>
>
> > > Please CC the bug-gnu-libicon
[resent to the cygwin list; please add bug-gnu-libiconv to your replies]
Hi Corinna,
Thanks for your reply <http://cygwin.com/ml/cygwin/2011-01/msg00410.html>
> > Please CC the bug-gnu-libiconv mailing list when discussing possible
> > bugs in GNU libiconv.
>
> Ok
Th
On Jan 29 19:12, Corinna Vinschen wrote:
> On Jan 29 10:21, Eric Blake wrote:
> > In other words, cygwin IS being POSIX-compliant by advertising only the
> > Unicode 4.0 character set in the __STDC_ISO_10646__, while still
Btw., you are aware that Unicode 4.0 already defines more characters than
f
On Jan 29 10:21, Eric Blake wrote:
> On 01/29/2011 09:01 AM, Corinna Vinschen wrote:
> >> So, using UTF-16 surrogate encodings for characters outside the basic
> >> plane violates POSIX, but it's the best we can do for those characters.
> >
> > Right, and we discussed this already on this list. O
[Duplicate message to honor the missing CC of bug-gnu-libic...@gnu.org]
On Jan 29 08:10, Eric Blake wrote:
> On 01/29/2011 05:30 AM, Corinna Vinschen wrote:
> >> But when characters outside the basic plane, such as
> >> U+12345 (CUNEIFORM SIGN URU TIMES KI), are encoded by 2 consecutive wchar_t
>
On 01/29/2011 09:01 AM, Corinna Vinschen wrote:
>> So, using UTF-16 surrogate encodings for characters outside the basic
>> plane violates POSIX, but it's the best we can do for those characters.
>
> Right, and we discussed this already on this list. Or the developer
> list, I don't remember. Ma
On Jan 29 08:10, Eric Blake wrote:
> On 01/29/2011 05:30 AM, Corinna Vinschen wrote:
> >> But when characters outside the basic plane, such as
> >> U+12345 (CUNEIFORM SIGN URU TIMES KI), are encoded by 2 consecutive wchar_t
> >> values, values of type wchar_t don't correspond to ISO/IEC 10646
> >>
On 01/29/2011 05:30 AM, Corinna Vinschen wrote:
>> But when characters outside the basic plane, such as
>> U+12345 (CUNEIFORM SIGN URU TIMES KI), are encoded by 2 consecutive wchar_t
>> values, values of type wchar_t don't correspond to ISO/IEC 10646 characters.
>> (Or maybe I'm underestimating wha
On Jan 28 22:06, Charles Wilson wrote:
> On 1/28/2011 5:12 PM, Bruno Haible wrote:
> >> the old cygwin_conv_to_posix_path function as well.
> >
> > Is cygwin_conv_to_posix_path deprecated? Does it introduce limitations of
> > some kind?
>
> Yes, and (and because:) yes.
>
> The limitation is, the
On Jan 28 23:12, Bruno Haible wrote:
> Hi Corinna and Chuck,
>
> Please CC the bug-gnu-libiconv mailing list when discussing possible
> bugs in GNU libiconv.
Ok, no worries. However, please remove my mail account from the CC.
I'm reading the cygwin ML anyway, so I don't n
.c, function get_charset_aliases() is
>> not good, not good at all.
>
> The alternative is to have this table stored in a file charset.alias;
> but then every package that includes the module 'localcharset' from
> gnulib (that is, libiconv, gettext, coreutils, and many
On 1/28/2011 5:12 PM, Bruno Haible wrote:
> Please CC the bug-gnu-libiconv mailing list when discussing possible
> bugs in GNU libiconv.
I hadn't intended on involving bug-gnu-libiconv until we had a working
fix, and a consensus here on @cygwin. But, in any case, here is the
portion o
Hi Corinna and Chuck,
Please CC the bug-gnu-libiconv mailing list when discussing possible
bugs in GNU libiconv.
Replying to <http://www.cygwin.com/ml/cygwin/2011-01/msg00292.html>:
> the application tests to convert a UTF-8 to WCHAR_T string in four
> combinations of the curren
On 1/25/2011 10:50 AM, Corinna Vinschen wrote:
>>> 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 tha
On 1/27/2011 11:44 PM, Charles Wilson wrote:
> [*] Note: proper compilation of libiconv itself requires an (as yet)
> unreleased version of cygwin (1.7.8). However, the compiled result
> operates correctly under cygwin-1.7.2 or later.
Well, the library components appear t
The GNU libiconv package provides an iconv() implementation, for use on
systems which don't have one, or whose implementation cannot convert
from/to Unicode.
[[ compiled using gcc-4.3.4-3 ]]
Changes since libiconv-1.13.1-1
o Rebuild against newer c
he removed all uses of path conversion code, by staying solely posix
throughout, making that a non-issue).
> But that's gnulib's problem, not
> cygwin's - don't let it stop us from making progress here.
Regardless of how upstream gnulib adapts, I can (and will) patch
support old, unsupported Cygwin versions. There are existing, older
>> builds of libiconv available for them.
>
> But I'm not (really) talking about libiconv. I'm talking about a
> proposed patch for gnulib -- which is a *source based repository* meant
> to be import
for instance, upstream git.
> The changes
> should work with versions at least back to 1.7.2 and I don't care the
> least for older versions. There's no reason to clutter the code to
> support old, unsupported Cygwin versions. There are existing, older
> builds of libiconv av
ined __WIN32__ || defined
> > __CYGWIN__
> >
> > Other than that, here's the full patchset which I applied to let
> > libiconv work more POSIXy on Cygwin. I tested especially that the Linux
> > code works fine on Cygwin as well. Use the patch at you own leasure.
&
> !defined __CYGWIN__)
>
> This should be
>
> #if __STDC_ISO_10646__ || defined _WIN32 || defined __WIN32__
> ...
> #if __STDC_ISO_10646__ || defined _WIN32 || defined __WIN32__ || defined
> __CYGWIN__
>
> Other than that, here's the full patchset which
On 1/27/2011 4:25 AM, Corinna Vinschen wrote:
> On Jan 26 22:12, Charles Wilson wrote:
>> Can we get a newer snapshot that the current 20110117?
>
> Done.
Thanks. Will try again (with today's snap #2) tonight.
--
Chuck
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On Jan 26 22:09, Charles Wilson wrote:
> On 1/24/2011 10:09 PM, Charles Wilson wrote:
> > Now, since there has not yet been an updated upstream release of
> > libiconv, my first step would be to simply rebuild our existing
> > libiconv-1.13.1 on a platform with current cygw
> If that doesn't correct the issue...then I'd try to run your test case
> on linux, but *explicitly* using libiconv on that system, rather than
> (as is typically the case on linux) relying on the underlying glibc
> implementation of iconv functionality.
>
On Jan 26 22:12, Charles Wilson wrote:
> On 1/25/2011 6:15 AM, Corinna Vinschen wrote:
> > - 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. Please note that I defined
On 1/25/2011 6:15 AM, Corinna Vinschen wrote:
> - 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. Please note that I defined
> __STDC_ISO_10646__ for Cygwin 1.7.8 yesterd
On 1/24/2011 10:09 PM, Charles Wilson wrote:
> Now, since there has not yet been an updated upstream release of
> libiconv, my first step would be to simply rebuild our existing
> libiconv-1.13.1 on a platform with current cygwin (1.7.7-1), and try the
> test case again.
Rebuilt libi
2 - 20) = 492 bytes.
> >> In the last case all 16 bytes are consumed so there remains in
> >> the buffer (512 - 32) = 480 bytes.
> >
> > Yes, you're right. Quite obviously I misinterpreted the results without
> > realizing that the buffer is smaller unde
s 512 bytes.
>> In the first 3 cases, 10 input bytes were consumed so that there remains
>> in the buffer (512 - 20) = 492 bytes.
>> In the last case all 16 bytes are consumed so there remains in
>> the buffer (512 - 32) = 480 bytes.
>
> Yes, you're right. Quit
On Jan 26 13:15, si...@sim-basis.de wrote:
> > Here's what happens on Cygwin:
> >
> > $ gcc -g -o ic ic.c -liconv
> > $ ./ic
> > iconv: 138
> > in = , inbuf = <ä sana>, inbytesleft = 7,
> outbytesleft = 492
> > iconv: 138
> > in = , inbuf = <ä sana>, inbytesleft = 7,
> outbytesleft = 492
>
> Here's what happens on Cygwin:
>
> $ gcc -g -o ic ic.c -liconv
> $ ./ic
> iconv: 138
> in = , inbuf = <ä sana>, inbytesleft = 7,
outbytesleft = 492
> iconv: 138
> in = , inbuf = <ä sana>, inbytesleft = 7,
outbytesleft = 492
> iconv: 138
> in = , inbuf = <ä sana>, inbytesleft = 7,
ou
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/
platform's behavior vis character sets.
>
> Ok, but that doesn't mean it has to stumble over its own feet if the
> current locale's codeset is different from the codeset which has to
> be converted.
True, of course. I was just thinking that *maybe* just recompiling
g. See
http://pubs.opengroup.org/onlinepubs/9699919799/functions/nl_langinfo.html
"Calls to setlocale() with a category corresponding to the category of
item (see ), or to the category LC_ALL , may overwrite the
array pointed to by the return value."
That's what happens i
there by any chance a newer version of
> libiconv2 which does not have these problems?
Well, iconv's behavior is very dependent on detailed characteristics of
the system on which it was compiled -- e.g. it's very finicky about the
platform's behavior vis character sets.
Now, cygwin's lib
Hi Chuck,
hi everyone else,
In a twisted turn of events, I'm trying to get the orphaned catgets
package to work correctly on Cygwin 1.7. As you might know, the package
is derived from the glibc package. Apart from other portability issues
of this *very* glibc-centric piece of code, I found some
--- 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 is
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/
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 overw
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 */
ty
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
Hi,
hitting against a undefined reference to `_iconv'
when linking against -liconv
I noticed that
$ nm /usr/lib/libiconv.dll.a |grep T |grep iconv
T _libiconvlist
T _libiconvctl
T _libiconv_set_relocation_prefix
T _libiconv_relocate
T _libiconv_open_in
On 3/13/2010 1:36 AM, Roger While wrote:
> gettext supplies libintl.la.
> That file requires libiconv.la.
That is what would be supported by a 'build-depends:' tag -- which is
exactly how that is handled by more powerful package management systems
like rpm, deb, apt, and even ebuild.
The origina
e configure proceeds and produces something like -
>
> checking for GNU gettext in libc... no
> checking for iconv... no, consider installing GNU libiconv
> checking for GNU gettext in libintl... yes
> checking whether to use NLS... yes
> checking where the gettext function comes from.
produces something like -
>
> checking for GNU gettext in libc... no
> checking for iconv... no, consider installing GNU libiconv
> checking for GNU gettext in libintl... yes
> checking whether to use NLS... yes
> checking where the gettext function comes from... external l
something like -
checking for GNU gettext in libc... no
checking for iconv... no, consider installing GNU libiconv
checking for GNU gettext in libintl... yes
checking whether to use NLS... yes
checking where the gettext function comes from... external libintl
checking how to link with libintl... -lintl
libc... no
checking for iconv... no, consider installing GNU libiconv
checking for GNU gettext in libintl... yes
checking whether to use NLS... yes
checking where the gettext function comes from... external libintl
checking how to link with libintl... -lintl
etc.
Also fine.
We then do the make which
The GNU libiconv package provides an iconv() implementation, for use on
systems which don't have one, or whose implementation cannot convert
from/to Unicode.
[[ compiled using gcc-4.3.4-3 ]]
As expected now that cygwin-1.7.1 has been officially released, this
libiconv package is avai
*, 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 (w
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
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, s
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&#
The GNU libiconv package provides an iconv() implementation, for use on
systems which don't have one, or whose implementation cannot convert
from/to Unicode.
[[ compiled using gcc-3.4.4-999 ]]
This will most likely be the final libiconv update for the cygwin-1.5
distribution; future develo
The GNU libiconv package provides an iconv() implementation, for use on
systems which don't have one, or whose implementation cannot convert
from/to Unicode.
[[ compiled using gcc-3.4.4-999 ]]
This release was compiled specifically for cygwin-1.7. In addition to
taking advantage o
Victor Paesa wrote:
> The Xpm-noX library seems to depend on libintl, libiconv:
>
> $ grep ^dependency_libs /usr/lib/noX/libXpm-noX.la
> dependency_libs=' -lgdi32 -luser32 /usr/lib/libintl.la -L/usr/lib
> /usr/lib/libiconv.la'
...
> I believe libXpm-noX does not really
Hi,
The Xpm-noX library seems to depend on libintl, libiconv:
$ grep ^dependency_libs /usr/lib/noX/libXpm-noX.la
dependency_libs=' -lgdi32 -luser32 /usr/lib/libintl.la -L/usr/lib
/usr/lib/libiconv.la'
But cygcheck reports it does not:
$ cygcheck /bin/cygXpm-noX-4.dll
C:\cygwin17\
The GNU libiconv package provides an iconv() implementation, for use on
systems which don't have one, or whose implementation cannot convert
from/to Unicode.
This is the first release specific for cygwin-1.7. The only differences
between this package and the earlier libiconv-0.12-1 (release
The GNU libiconv package provides an iconv() implementation, for use on
systems which don't have one, or whose implementation cannot convert
from/to Unicode.
These should be upgraded together with the gettext packages.
libiconv-1.12-1
libiconv2-1.12-1
libcharset1-1.12-1
ge
y. The issue is that you
accidently overwrote the libiconv header with the newlib header of the
same name (iconv.h). You get that if you a make install (or whatever)
for newlib to get updates headers. The newlib one doesn't work
obviously because it simply defines iconv_open. The prope
On 11 February 2008 19:13, Reini Urban wrote:
> 2008/2/11, Dave Korn <[EMAIL PROTECTED]>:
>> Does anyone understand the difference between iconv_open and
>> libiconv_open, and why the libiconv package supplies a header that
>> declares only iconv_XXX and
2008/2/11, Dave Korn <[EMAIL PROTECTED]>:
> Does anyone understand the difference between iconv_open and libiconv_open,
> and why the libiconv package supplies a header that declares only iconv_XXX
> and a library that defines only libiconv_? I find this confusing, and so
>
Does anyone understand the difference between iconv_open and libiconv_open,
and why the libiconv package supplies a header that declares only iconv_XXX
and a library that defines only libiconv_? I find this confusing, and so
does ./configure and friends.
cheers,
DaveK
The GNU libiconv package provides an iconv() implementation, for use on
systems which don't have one, or whose implementation cannot convert
from/to Unicode.
These should be upgraded together with the gettext packages.
libiconv-1.11-1
libiconv2-1.11-1
libcharset1-1
On Thu, Jun 29, 2006 at 01:57:04PM +0200, Christian Joensson wrote:
>sigh, definitely quitting now...
>
>CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' ../src/configure
>--build=i686-pc-cygwin --host=i686-pc-mingw32
>--target=i686-pc-mingw32--prefix=/opt/mingw
>
>still, again,
>
>/bin/sh ./libtool --mo
sigh, definitely quitting now...
CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' ../src/configure
--build=i686-pc-cygwin --host=i686-pc-mingw32
--target=i686-pc-mingw32--prefix=/opt/mingw
still, again,
/bin/sh ./libtool --mode=link gcc -mno-cygwin -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -W
c-cygwin --host=i686-pc-mingw32
--target=i686-pc-mingw32. Without --host it assumes that host=build,
and tries to make a Cygwin binary, which fails since you're using mingw
gcc. This is only necessary for toolchains, for regular libraries (e.g.
gmp and libiconv) you should only need --host
nah... using
CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' ../src/configure \
--build=i686-pc-cygwin --target=i686-pc-mingw32 --prefix=/opt/mingw
I get into this problem:
gcc -mno-cygwin -c -DHAVE_CONFIG_H -g -O2 -I.
-I../../src/libiberty/../include -W -Wall -pedantic -Wwrite-strings
-Wstr
Christian Joensson wrote:
>
> Thanks so far.
>
> Right now, I do this:
>
> $ CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin'
> ../binutils-060628/configure --build=i686-pc-cygwin
> --host=i686-pc-mingw32 --prefix=/opt/mingw
>
> But I get stuck like this:
In the case of toolchains (i.e. packages tha
Thanks so far.
Right now, I do this:
$ CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin'
../binutils-060628/configure --build=i686-pc-cygwin
--host=i686-pc-mingw32 --prefix=/opt/mingw
But I get stuck like this:
gcc -mno-cygwin -c -DHAVE_CONFIG_H -g -O2 -I.
-I../../binutils-060628/libiberty/../include
Brian Dessent wrote:
> syntax. You really should use --host=i686-pc-mingw
s/i686-pc-mingw/i686-pc-mingw32/, although I'm not sure if it's
critical.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: ht
Christian Joensson wrote:
> I'm starting to look at cygwin for doing mingw "environment" variants
> of binutils and gcc, to test compile them.
>
> Now, starting with binutils, I do this:
>
> CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' ../src/configure i686-pc-mingw32
Specifying a non-option host
Christian Joensson wrote:
I'm starting to look at cygwin for doing mingw "environment" variants
of binutils and gcc, to test compile them.
Now, starting with binutils, I do this:
CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' ../src/configure i686-pc-mingw32
and then a regular make.
I notice, but
tice, but I really don't require it here, that gmp is missing. Is
that, gmp as mingw variant under cygwin, available to download? If
not, how would you suggest I configure, build and install them local
to me?
Next, I also get configure warnings about libiconv not being
installed.. same qu
The GNU libiconv package provides an iconv() implementation, for use on
systems which don't have one, or whose implementation cannot convert
from/to Unicode.
Changes since libiconv-1.9.2-1
* non-user visible maintainance update
* recompiled against recent gettext release
--
Chuck
*** C
1 - 100 of 131 matches
Mail list logo
