Re: [ITA] libiconv-1.16-1, libiconv2-1.16, libcharset1-1.16-1
Date: Fri, 31 Jul 2020 06:22:21 +0200 From: Marco Atzeri via Cygwin-apps > On 30.07.2020 21:38, Lemures Lemniscati via Cygwin-apps wrote: > > > > > By the way, when should I promote libiconv-1.16-2 from test to current? > > when you are confident about it. ;-) > > > > But, I don't know how to promote. > > Should I rebuild and release as libiconv-1.16-3 ? > > No. Just remove the "test:" rows from the hint files and re-upload them > > "calm" does not accept new tar files with the same name, but accept > replacement for the hint files. > Usually I upload them with lftp, so I do not know if the cygport way > have some issues. > > If you have problem, I can modify the hint files directly on > the repository Thank you, Marco. I've tried cygport. And it uploads them. Now, setup.ini is updated. Regards, Lem
Re: [ITA] libiconv-1.16-1, libiconv2-1.16, libcharset1-1.16-1
On 30.07.2020 21:38, Lemures Lemniscati via Cygwin-apps wrote: By the way, when should I promote libiconv-1.16-2 from test to current? when you are confident about it. ;-) But, I don't know how to promote. Should I rebuild and release as libiconv-1.16-3 ? No. Just remove the "test:" rows from the hint files and re-upload them "calm" does not accept new tar files with the same name, but accept replacement for the hint files. Usually I upload them with lftp, so I do not know if the cygport way have some issues. If you have problem, I can modify the hint files directly on the repository Regards, Lem Regards Marco
Re: [ITA] libiconv-1.16-1, libiconv2-1.16, libcharset1-1.16-1
Date: Sat, 18 Jul 2020 20:18:27 +0900 From: Lemures Lemniscati > Date: Sat, 18 Jul 2020 12:45:35 +0200 > From: Achim Gratz > > > Lemures Lemniscati via Cygwin-apps writes: > > > I've prepared it at a branch w_build-requires in the repository > > > https://cygwin.com/git/cygwin-packages/libiconv.git . > > > > > > But not merged yet to master branch. > > > > You should push experiments to the playground branch, which you can > > force-push and delete without intervention from Jon. You can check the > > CI results here: > > > > https://cygwin.com/cgi-bin2/jobs.cgi > > https://ci.appveyor.com/project/cygwin/scallywag/history > > > > Very wonderful! > Thank you. By the way, when should I promote libiconv-1.16-2 from test to current? But, I don't know how to promote. Should I rebuild and release as libiconv-1.16-3 ? Regards, Lem
Re: [ITA] libiconv-1.16-1, libiconv2-1.16, libcharset1-1.16-1
Date: Sat, 18 Jul 2020 12:45:35 +0200 From: Achim Gratz > Lemures Lemniscati via Cygwin-apps writes: > > I've prepared it at a branch w_build-requires in the repository > > https://cygwin.com/git/cygwin-packages/libiconv.git . > > > > But not merged yet to master branch. > > You should push experiments to the playground branch, which you can > force-push and delete without intervention from Jon. You can check the > CI results here: > > https://cygwin.com/cgi-bin2/jobs.cgi > https://ci.appveyor.com/project/cygwin/scallywag/history > Very wonderful! Thank you. Lem
Re: [ITA] libiconv-1.16-1, libiconv2-1.16, libcharset1-1.16-1
Lemures Lemniscati via Cygwin-apps writes: > I've prepared it at a branch w_build-requires in the repository > https://cygwin.com/git/cygwin-packages/libiconv.git . > > But not merged yet to master branch. You should push experiments to the playground branch, which you can force-push and delete without intervention from Jon. You can check the CI results here: https://cygwin.com/cgi-bin2/jobs.cgi https://ci.appveyor.com/project/cygwin/scallywag/history Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [ITA] libiconv-1.16-1, libiconv2-1.16, libcharset1-1.16-1
Date: Sat, 18 Jul 2020 10:29:15 +0200 From: Achim Gratz > When you next build the libiconv package, please add BUILD_REQUIRES so > the CI can try to build it. Currently it's missing at least gperf from > the CI build environment. All right, Achim. I've prepared it at a branch w_build-requires in the repository https://cygwin.com/git/cygwin-packages/libiconv.git . But not merged yet to master branch. Regards, Lem
Re: [ITA] libiconv-1.16-1, libiconv2-1.16, libcharset1-1.16-1
When you next build the libiconv package, please add BUILD_REQUIRES so the CI can try to build it. Currently it's missing at least gperf from the CI build environment. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [ITA] libiconv-1.16-1, libiconv2-1.16, libcharset1-1.16-1
On Sat, 2020-07-11 at 19:45 +0200, Marco Atzeri via Cygwin-apps wrote: > On 11.07.2020 04:03, Lemures Lemniscati via Cygwin-apps wrote: > > Hi! > > > > I suggest an update to libiconv 1.16, since the current Cygwin > > packages of libiconv 1.14 are old (updated 5 years ago). > > > > Cygport files are forked > > to https://github.com/cygwin-lem/libiconv-cygport/tree/w_1.16 > > from http://cygwin.com/git/cygwin-packages/libiconv . > > > > > > New test package files are placed here: > > https://cygwin-lem.github.io/libiconv-cygport/index.html . > > > > Please, check them: > > Looks good to me > > except the build of static import libraries > > usr/lib/libcharset.a > usr/lib/libiconv.a > > I will stick to only: > usr/lib/libcharset.dll.a > usr/lib/libiconv.dll.a Static libiconv is used when building Cygwin dumper.exe (as a dependency of libbfd.a, which is static only). Therefore it should be present. Note that my .cygport has an explicit --enable-static, which should have indicated that this was deliberate. -- Yaakov
Re: [ITA] libiconv-1.16-1, libiconv2-1.16, libcharset1-1.16-1
Date: Sat, 11 Jul 2020 19:45:59 +0200 From: Marco Atzeri > On 11.07.2020 04:03, Lemures Lemniscati via Cygwin-apps wrote: > > Hi! > > > > I suggest an update to libiconv 1.16, since the current Cygwin > > packages of libiconv 1.14 are old (updated 5 years ago). > > > > Cygport files are forked > > to https://github.com/cygwin-lem/libiconv-cygport/tree/w_1.16 > > from http://cygwin.com/git/cygwin-packages/libiconv . > > > > > > New test package files are placed here: > > https://cygwin-lem.github.io/libiconv-cygport/index.html . > > > > Please, check them: > > > Looks good to me > > except the build of static import libraries > > usr/lib/libcharset.a > usr/lib/libiconv.a > > I will stick to only: > usr/lib/libcharset.dll.a > usr/lib/libiconv.dll.a > > > Please follow > https://cygwin.com/packaging/key.html#sshkey Thank you for reviewing. Modified cygport related files: https://github.com/cygwin-lem/libiconv-cygport/tree/w_1.16 Modified test package files: https://cygwin-lem.github.io/libiconv-cygport/index.html . -- Lem
Re: [ITA] libiconv-1.16-1, libiconv2-1.16, libcharset1-1.16-1
On 11.07.2020 04:03, Lemures Lemniscati via Cygwin-apps wrote: Hi! I suggest an update to libiconv 1.16, since the current Cygwin packages of libiconv 1.14 are old (updated 5 years ago). Cygport files are forked to https://github.com/cygwin-lem/libiconv-cygport/tree/w_1.16 from http://cygwin.com/git/cygwin-packages/libiconv . New test package files are placed here: https://cygwin-lem.github.io/libiconv-cygport/index.html . Please, check them: Looks good to me except the build of static import libraries usr/lib/libcharset.a usr/lib/libiconv.a I will stick to only: usr/lib/libcharset.dll.a usr/lib/libiconv.dll.a Please follow https://cygwin.com/packaging/key.html#sshkey -- Lem Thanks Marco
[ITA] libiconv-1.16-1, libiconv2-1.16, libcharset1-1.16-1
Hi! I suggest an update to libiconv 1.16, since the current Cygwin packages of libiconv 1.14 are old (updated 5 years ago). Cygport files are forked to https://github.com/cygwin-lem/libiconv-cygport/tree/w_1.16 from http://cygwin.com/git/cygwin-packages/libiconv . New test package files are placed here: https://cygwin-lem.github.io/libiconv-cygport/index.html . Please, check them: x86/libiconv/libcharset1/libcharset1-1.16-1.hint x86/libiconv/libcharset1/libcharset1-1.16-1.tar.xz x86/libiconv/libiconv-1.16-1-src.hint x86/libiconv/libiconv-1.16-1-src.tar.xz x86/libiconv/libiconv-1.16-1.hint x86/libiconv/libiconv-1.16-1.tar.xz x86/libiconv/libiconv-debuginfo/libiconv-debuginfo-1.16-1.hint x86/libiconv/libiconv-debuginfo/libiconv-debuginfo-1.16-1.tar.xz x86/libiconv/libiconv-devel/libiconv-devel-1.16-1.hint x86/libiconv/libiconv-devel/libiconv-devel-1.16-1.tar.xz x86/libiconv/libiconv2/libiconv2-1.16-1.hint x86/libiconv/libiconv2/libiconv2-1.16-1.tar.xz x86_64/libiconv/libcharset1/libcharset1-1.16-1.hint x86_64/libiconv/libcharset1/libcharset1-1.16-1.tar.xz x86_64/libiconv/libiconv-1.16-1-src.hint x86_64/libiconv/libiconv-1.16-1-src.tar.xz x86_64/libiconv/libiconv-1.16-1.hint x86_64/libiconv/libiconv-1.16-1.tar.xz x86_64/libiconv/libiconv-debuginfo/libiconv-debuginfo-1.16-1.hint x86_64/libiconv/libiconv-debuginfo/libiconv-debuginfo-1.16-1.tar.xz x86_64/libiconv/libiconv-devel/libiconv-devel-1.16-1.hint x86_64/libiconv/libiconv-devel/libiconv-devel-1.16-1.tar.xz x86_64/libiconv/libiconv2/libiconv2-1.16-1.hint x86_64/libiconv/libiconv2/libiconv2-1.16-1.tar.xz -- Lem
[Ready for test/1.5.1] libiconv gettext (many)
These two package-sets should be updated together. * compiled against cygwin-1.5.1 kernel * documentation moved to /usr/share/* libiconv-1.9.1-2 libiconv2-1.9.1-2 libcharset1-1.9.1-2 gettext-0.12.1-2 gettext-devel-0.12.1-2 libintl2-0.12.1-2 libgettextpo0-0.12.1-2 (*) (*) new library package -- gettext-devel now depends on it. Both libiconv and gettext packages were COMPLETELY reorganized between (libiconv: 1.8 - 1.9.1, gettext: 0.11.5 - 0.12.1), so expect warts. (On the plus side, these packages passed their internal selftests for the most part (better compliance than their predecessors) so they're probably okay) -- Charles Wilson cygwin at removespam cwilson dot fastmail dot fm
Re: libiconv gettext (many)
On Fri, Jul 25, 2003 at 12:48:11AM -0400, Charles Wilson wrote: These two package-sets should be updated together. libiconv-1.9.1-1 libiconv2-1.9.1-1 libcharset1-1.9.1-1 gettext-0.12.1-1 gettext-devel-0.12.1-1 libintl2-0.12.1-1 libgettextpo0-0.12.1-1 (*) The gettext manpages were installed into usr/share/man/* Actually, now that I think about this, is it so bad? /usr/share/man/* IS in the FHS. Would it be so awful to (a) allow both /usr/share/man and /usr/man, and/or gradually transition to a more compliant (e.g. /usr/share/man) hierarchy? I had the same thought. I don't have any problems with the gradual adoption of /usr/share/man, as long as the man command works with it, of course. I wish we'd used /usr/share/man from the start, in fact. Oh well. As they say at Red Hat We are still learning. cgf
Re: libiconv gettext (many)
On Fri, 25 Jul 2003, Christopher Faylor wrote: On Fri, Jul 25, 2003 at 12:48:11AM -0400, Charles Wilson wrote: These two package-sets should be updated together. libiconv-1.9.1-1 libiconv2-1.9.1-1 libcharset1-1.9.1-1 gettext-0.12.1-1 gettext-devel-0.12.1-1 libintl2-0.12.1-1 libgettextpo0-0.12.1-1 (*) The gettext manpages were installed into usr/share/man/* Actually, now that I think about this, is it so bad? /usr/share/man/* IS in the FHS. Would it be so awful to (a) allow both /usr/share/man and /usr/man, and/or gradually transition to a more compliant (e.g. /usr/share/man) hierarchy? I had the same thought. I don't have any problems with the gradual adoption of /usr/share/man, as long as the man command works with it, of course. I wish we'd used /usr/share/man from the start, in fact. Oh well. As they say at Red Hat We are still learning. I prefer the FHS compilant approach, too. If you like I'll change the default man path when I update man. As 1.5.0 has a lot of changes maybe now would be a good time to change everything and add some more mean'ness. ;-) Seriously, if we want to change where everything sits now is the perfect time to do so. As they say at SCO We are still bastards. Sorry, had to let off some steam... -- Elfyn McBratney, EMCB | http://www.nongnu.org/wwwauth/ http://www.emcb.co.uk | http://www.emcb.co.uk/webauth/ [EMAIL PROTECTED] | wwwauth-users AT nongnu DOT org
Re: libiconv gettext (many)
[EMAIL PROTECTED] wrote: These two package-sets should be updated together. libiconv-1.9.1-1 libiconv2-1.9.1-1 libcharset1-1.9.1-1 gettext-0.12.1-1 gettext-devel-0.12.1-1 libintl2-0.12.1-1 libgettextpo0-0.12.1-1 (*) The gettext manpages were installed into usr/share/man/* Actually, now that I think about this, is it so bad? /usr/share/man/* IS in the FHS. Would it be so awful to (a) allow both /usr/share/man and /usr/man, and/or gradually transition to a more compliant (e.g. /usr/share/man) hierarchy? I totally agree, transitioning to share/man share/info would be a Good Thing. Cheers, Nicholas
Re: libiconv gettext (many)
[EMAIL PROTECTED] wrote: On Fri, Jul 25, 2003 at 12:48:11AM -0400, Charles Wilson wrote: These two package-sets should be updated together. libiconv-1.9.1-1 libiconv2-1.9.1-1 libcharset1-1.9.1-1 gettext-0.12.1-1 gettext-devel-0.12.1-1 libintl2-0.12.1-1 libgettextpo0-0.12.1-1 (*) The gettext manpages were installed into usr/share/man/* Actually, now that I think about this, is it so bad? /usr/share/man/* IS in the FHS. Would it be so awful to (a) allow both /usr/share/man and /usr/man, and/or gradually transition to a more compliant (e.g. /usr/share/man) hierarchy? I had the same thought. I don't have any problems with the gradual adoption of /usr/share/man, as long as the man command works with it, of course. I wish we'd used /usr/share/man from the start, in fact. Oh well. While we're at it, It Would Be Nice to start transitioning to bzip2 compressed manpages, now that our man supports them. This wasn't so much a problem when Cygwin had only a few packages, but now the man directory is starting to get a little bloated. I'm not sure if our texinfo/pinfo supports them, but bzip2ing the info's would be great as well. Just a thought... Cheers, Nicholas
Re: libiconv gettext (many)
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: [SNIP] I had the same thought. I don't have any problems with the gradual adoption of /usr/share/man, as long as the man command works with it, of course. I wish we'd used /usr/share/man from the start, in fact. Oh well. While we're at it, It Would Be Nice to start transitioning to bzip2 compressed manpages, now that our man supports them. This wasn't so much a problem when Cygwin had only a few packages, but now the man directory is starting to get a little bloated. I'm not sure if our texinfo/pinfo supports them, but bzip2ing the info's would be great as well. Just a thought... To follow up on this, I've gathered some statics based on a COMPLETE install of all current and testing packages. Bear in mind that I did this on FAT32, so the space savings won't be as good as it would be on NTFS. Also note that I did NOT recompress the gzipped manpages from the manpages package in bzip2 format. /usr/man before compression: ~18MB (~33MB on disk for FAT32) /usr/man after compression with `bzip2 -9`: ~6MB (~22MB on disk for FAT32) Again, NTFS will likely show better results, but the results still show the advantages clearly. FWIW, I noticed absolutely no significant delay in displaying compressed manpages as compared to uncompressed manpages. Cheers, Nicholas
unsupported/ (was Re: libiconv gettext (many))
On Fri, 25 Jul 2003, Christopher Faylor wrote: On Fri, Jul 25, 2003 at 12:48:11AM -0400, Charles Wilson wrote: These two package-sets should be updated together. libiconv-1.9.1-1 libiconv2-1.9.1-1 libcharset1-1.9.1-1 gettext-0.12.1-1 gettext-devel-0.12.1-1 libintl2-0.12.1-1 libgettextpo0-0.12.1-1 (*) The gettext manpages were installed into usr/share/man/* Actually, now that I think about this, is it so bad? /usr/share/man/* IS in the FHS. Would it be so awful to (a) allow both /usr/share/man and /usr/man, and/or gradually transition to a more compliant (e.g. /usr/share/man) hierarchy? I had the same thought. I don't have any problems with the gradual adoption of /usr/share/man, as long as the man command works with it, of course. I wish we'd used /usr/share/man from the start, in fact. Oh well. As they say at Red Hat We are still learning. This talk of adhering the FHS made me remember Chuck's proposal for an 'unsupported/' dir (http://www.cygwin.com/ml/cygwin-apps/2003-04/msg00306.html) in ~ftp/pub/cygwin . Chris raised some concerns about the cygwin mailing list filling up with lot's of musings about the 'unsupported' packages, but I think there's a way we can have an unsupported range of packages without the noise: integrate these 'unsupported' offerings with the Software list on the cygwin home page. Any thoughts? Elfyn -- Elfyn McBratney, EMCB | http://www.nongnu.org/wwwauth/ http://www.emcb.co.uk | http://www.emcb.co.uk/webauth/ [EMAIL PROTECTED] | wwwauth-users AT nongnu DOT org
Re: [Ready for test/1.5.0] libiconv gettext (many)
On Wed, Jul 16, 2003 at 11:57:56PM -0400, Charles Wilson wrote: Corinna Vinschen wrote: localedir = bindtextdomain (PACKAGE, LOCALEDIR); ... puts (localedir); Am I right here? I had not much to do with libintl so far so please excuse my questions. No, I think that actually SETS the localedir to the appropriate subdirectory under the specified LOCALEDIR. You want to know where it would look by *default*, so instead of (for instance) /usr/share/locale [the value of _nl_default_dirname, you get LOCALEDIR/domain/PACKAGE.po [...] Thanks for the description. It convinced me that my above code is correct ;-) The thing is, the code actually already calls bindtextdomain (PACKAGE, LOCALEDIR); unconditionally. So the correct locale dir is known to the application but not used later when --print-text-domain-dir is given on the command line. The man page of shar says: --print-text-domain-dir Prints the directory shar looks in to find messages files for different languages, then immediately exits. So it's not the systems default dir but the directory shar is looking in, the one set with bindtextdomain. Now there's just one configury problem left. Setting datadir on the command line doesn't help. It's always /usr/lib later on. Or, if I use --with-gnu-gettext, it always builds and links against the own libintl.a :-( Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [Ready for test/1.5.0] libiconv gettext (many)
Corinna Vinschen wrote: On Tue, Jul 15, 2003 at 08:42:04PM -0400, Charles Wilson wrote: Real fix: figure out why sharutils thinks it needs access to that variable, and use the public API to do the same thing. If possible. shar just uses the value to print it to stdout if the option --print-text-domain-dir is given. AFAICS, printing this value is even wrong. The correct value is the one returned by a former call to bindtextdomain(), right? So I'd guess the correct solution would be to store the return value of bindtextdomain() and to use this to print: localedir = bindtextdomain (PACKAGE, LOCALEDIR); ... puts (localedir); Am I right here? I had not much to do with libintl so far so please excuse my questions. No, I think that actually SETS the localedir to the appropriate subdirectory under the specified LOCALEDIR. You want to know where it would look by *default*, so instead of (for instance) /usr/share/locale [the value of _nl_default_dirname, you get LOCALEDIR/domain/PACKAGE.po Believe it or not, here's how gettext.exe determines the default value of the localdir (under which there are languauge-secific subdirectories, etc etc). This code snippet is from the section that generates the --help output: ... Standard search directory: %s\n), getenv (IN_HELP2MAN) == NULL ? LOCALEDIR : @localedir@); See that? It actually relies on autoconf to HARDCODE the correct value! (But it doesn't illegally access dcigettext's _nl_default_dirname variable) -- or it uses LOCALDIR, which is a define passed in via the makefile (gcc -DLOCALEDIR=\$(localedir)\ ...) And, of course, in dcigettext, _nl_default_dirname[] itself is initialized with const char _nl_default_dirname[] = LOCALEDIR; So it appears there really is no way to get this value, except by accessing _nl_default_dirname. But you don't know if it is there or not -- it might be _nl_... if the gettext in question is part of the libc; or if you're using an external library (like libintl or cygintl) then it might be libintl_nl_... The only way to automatically figure this out is to, within configure, piggyback on the internal variables set by the stuff from gettext.m4: --- in configure.ac --- if test $gt_cv_func_gnugettext_lib == yes; then NL_DEFAULT_DIRNAME_VAR=_nl_default_dirname else NL_DEFAULT_DIRNAME_VAR=libintl_nl_default_dirname fi AC_SUBST([NL_DEFAULT_DIRNAME_VAR]) --- in Makefile.am/.in --- nl_default_dirname_var = @NL_DEFAULT_DIRNAME_VAR@ DEFS = -D_nl_default_dirname=$(nl_default_dirname_var) @DEFS@ -- BTW, the following is the configure.ac incantation that I use in order to force NOT build and NOT link against the local intl/ directory: AM_GNU_GETTEXT(external,[],[]) BUILD_INCLUDED_LIBINTL=no USE_INCLUDED_LIBINTL=no AC_SUBST(BUILD_INCLUDED_LIBINTL) AC_SUBST(USE_INCLUDED_LIBINTL) --Chuck -- Charles Wilson cygwin at removespam cwilson dot fastmail dot fm
Re: [Ready for test/1.5.0] libiconv gettext (many)
Charles, On Mon, Jul 14, 2003 at 04:32:55AM -0400, Charles Wilson wrote: These two package-sets should be updated together. libiconv-1.9.1-1 libiconv2-1.9.1-1 libcharset1-1.9.1-1 gettext-0.12.1-1 gettext-devel-0.12.1-1 libintl2-0.12.1-1 libgettextpo0-0.12.1-1 (*) trying to build sharutils for 1.5.0, I've just came across a problem: gcc -o shar shar.o encode.o ../lib/libshar.a ../lib/libshar.a -lintl -lintl shar.o(.text+0x5523): In function `main': /home/corinna/src/sharutils-4.2.1/src/shar.c:1970: undefined reference to `__imp___nl_default_dirname__' `nm /usr/lib/libintl.dll.a' shows only a symbol __imp__libintl_nl_default_dirname. The sharutils configury recognizes that the system has libintl.a but is too dumb to remove the own intl subdir from the include paths. So I thought this might be an incompatibility between the intl version in sharutils and our own version. I removed all include paths to its own intl dir by hand and built again. But the error persists. Then I had a look into the file which produces the error and I found this: #ifdef __CYGWIN__ extern const char __declspec(dllimport) _nl_default_dirname__[]; puts (_nl_default_dirname__); #else extern const char _nl_default_dirname[]; /* Defined in dcgettext.c */ puts (_nl_default_dirname); #endif What's the error here? Is the sharutils code plain wrong or is that an incompatibility of the new libintl? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [Ready for test/1.5.0] libiconv gettext (many)
Corinna Vinschen wrote: trying to build sharutils for 1.5.0, I've just came across a problem: gcc -o shar shar.o encode.o ../lib/libshar.a ../lib/libshar.a -lintl -lintl shar.o(.text+0x5523): In function `main': /home/corinna/src/sharutils-4.2.1/src/shar.c:1970: undefined reference to `__imp___nl_default_dirname__' `nm /usr/lib/libintl.dll.a' shows only a symbol __imp__libintl_nl_default_dirname. The sharutils configury recognizes that the system has libintl.a but is too dumb to remove the own intl subdir from the include paths. So I thought this might be an incompatibility between the intl version in sharutils and our own version. I removed all include paths to its own intl dir by hand and built again. But the error persists. Then I had a look into the file which produces the error and I found this: #ifdef __CYGWIN__ extern const char __declspec(dllimport) _nl_default_dirname__[]; puts (_nl_default_dirname__); #else extern const char _nl_default_dirname[]; /* Defined in dcgettext.c */ puts (_nl_default_dirname); #endif What's the error here? Is the sharutils code plain wrong or is that an incompatibility of the new libintl? Sharutils is wrong, in two ways. First, _nl_default_dirname is an internal variable -- sharutils shouldn't be accessing it at all. Second, dcigettext.c defines it thus: #if !defined _LIBC # define _nl_default_default_domain libintl_nl_default_default_domain # define _nl_current_default_domain libintl_nl_current_default_domain # define _nl_default_dirname libintl_nl_default_dirname # define _nl_domain_bindings libintl_nl_domain_bindings #endif But sharutils doesn't take _LIBC into account. Quick-n-dirty fix: use libintl_ instead. -- Slightly better fix: add some configury magic. Make sure that the acinclude.m4 or aclocal.m4 contains the latest gettext.m4 code, and then add to configure.ac: if test $gt_cv_func_gnugettext_libc = yes # do stuff to set variables so that _nl_default_dirname doesn't get re#defined else # set the variables the other way so that it DOES get re#defined to libintl_nl_... fi -- Real fix: figure out why sharutils thinks it needs access to that variable, and use the public API to do the same thing. If possible. -- Charles Wilson cygwin at removespam cwilson dot fastmail dot fm
[Ready for test/1.5.0] libiconv gettext (many)
These two package-sets should be updated together. libiconv-1.9.1-1 libiconv2-1.9.1-1 libcharset1-1.9.1-1 gettext-0.12.1-1 gettext-devel-0.12.1-1 libintl2-0.12.1-1 libgettextpo0-0.12.1-1 (*) (*) new library package -- gettext-devel now depends on it. Because we do not have versioned requires AFAIK, this means that even people who are using the curr: gettext-devel will pick up the test: libgettextpo0 package as a dependency. However, this should be harmless. Both libiconv and gettext packages were COMPLETELY reorganized between (libiconv: 1.8 - 1.9.1, gettext: 0.11.5 - 0.12.1). So much so, that I would consider these packages to be new ports. Worse, they needed lots of care and feeding, plus new (cygwin-specific) code [thanks a bunch, Bruno...] Even after I got all the code just right, I still needed to compile libiconv install it compile libiconv (yes, again!) install it compile gettext install it compile gettext (yes, again!) install it -- compile libiconv AGAIN! install it compile libiconv ONE MORE TIME! install it compile gettext A FINAL TIME... My poor 450Mhz laptop was really tired... In any case, these new ports passed their internal selftests for the most part (better compliance than their predecessors) so they're probably okay. Here's hoping... -- Charles Wilson cygwin at removespam cwilson dot fastmail dot fm
Re: [Ready for test/1.5.0] libiconv gettext (many)
On Mon, 2003-07-14 at 18:32, Charles Wilson wrote: Because we do not have versioned requires AFAIK We do. Not extensively tested, but see the setup homepage for the syntax. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [Ready for test/1.5.0] libiconv gettext (many)
On 14 Jul 2003 18:37:21 +1000, Robert Collins [EMAIL PROTECTED] said: On Mon, 2003-07-14 at 18:32, Charles Wilson wrote: Because we do not have versioned requires AFAIK We do. Not extensively tested, but see the setup homepage for the syntax. Should I use it, in this case -- or is that just asking for trouble? -- Charles Wilson cygwin at removespam cwilson dot fastmail dot fm
Re: [Ready for test/1.5.0] libiconv gettext (many)
On Mon, 2003-07-14 at 18:47, Charles Wilson wrote: On 14 Jul 2003 18:37:21 +1000, Robert Collins [EMAIL PROTECTED] said: On Mon, 2003-07-14 at 18:32, Charles Wilson wrote: Because we do not have versioned requires AFAIK We do. Not extensively tested, but see the setup homepage for the syntax. Should I use it, in this case -- or is that just asking for trouble? one way to find out ;]. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
[Missing dependency] gettext should have requires: libiconv
/usr/lib/libiconv.la is given in /usr/lib/libintl.la(dependency_libs). Therefore, to link with it, the libiconv package must be installed. Max.
Re: libiconv
[Cleaning out my mailbox] On Tue, Jun 25, 2002 at 06:50:16AM -0400, Nicholas Wourms wrote: Now you can link gcc against libiconv ;-). FWIW, I hope I have done this. I added the libraries in the hopes that the gcc configury would find it. How do we determine if it worked? cgf
Re: libiconv
Christopher Faylor wrote: [Cleaning out my mailbox] On Tue, Jun 25, 2002 at 06:50:16AM -0400, Nicholas Wourms wrote: Now you can link gcc against libiconv ;-). FWIW, I hope I have done this. I added the libraries in the hopes that the gcc configury would find it. How do we determine if it worked? Well, it's obviously not linked in dynamically (which is probably good -- I think we want gcc to be static, except for cygwin1.dll). However, begin a dumb american, I can't think of anyway to test it since I never really learned how to deal with i8n issues (toldja I wasn't the best guy to maintain libiconv...) I wonder if our japanese users could test this out for us? Otherwise, I think you're going to have to look thru your build log (you did pipe build output to a logfile, right? g) --Chuck
Re: libiconv
On Wed, Jul 10, 2002 at 06:43:55PM -0400, Charles Wilson wrote: Christopher Faylor wrote: [Cleaning out my mailbox] On Tue, Jun 25, 2002 at 06:50:16AM -0400, Nicholas Wourms wrote: Now you can link gcc against libiconv ;-). FWIW, I hope I have done this. I added the libraries in the hopes that the gcc configury would find it. How do we determine if it worked? Well, it's obviously not linked in dynamically (which is probably good -- I think we want gcc to be static, except for cygwin1.dll). I just realized that it was pretty easy to check. I just have to look at the build logs. Nope. No -liconv. After all that trouble to install it, gcc only randomly detected it in certain directories. I don't think I'll make this a priority for the testing releases but I'll see if I can tweak something for the real release. cgf
Re: libiconv
Christopher Faylor wrote: I just realized that it was pretty easy to check. I just have to look at the build logs. Nope. No -liconv. After all that trouble to install it, gcc only randomly detected it in certain directories. I haven't looked at the gcc-3.1.1 source tree, but I know that gcc does weird things with autoconf (e.g. top-level configure.in is NOT an input to autoconf...). Anyway, my point: the real gettext.m4 from gettext-0.11.2 seems to have the appropriate code in it to check for both -lintl and -liconv if appropriate. Does gcc-3.1.1 use aclocal.m4/gettext.m4 to find gettext, or some homebrew stuff? I don't think I'll make this a priority for the testing releases but I'll see if I can tweak something for the real release. That's reasonable. --Chuck
RE: libiconv
I think you need to configure with --enable-nls \ --without-included-gettext \ For gcc-3.2 I get $ cygcheck cc1.exe Found: .\cc1.exe .\cc1.exe C:\cygwin\bin\cygwin1.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\NTDLL.DLL C:\cygwin\bin\cygintl-2.dll C:\cygwin\bin\cygiconv-2.dll $ cygcheck jc1.exe Found: .\jc1.exe .\jc1.exe C:\cygwin\bin\cygwin1.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\NTDLL.DLL C:\cygwin\bin\cygiconv-2.dll C:\cygwin\bin\cygintl-2.dll C:\cygwin\bin\cygz.dll Don't know if it works, but it passes the testsuites.
Re: libiconv
It's worth a try, but wasn't there a lot of work done recently in the top-level configury of gcc? You are probably benefitting from that; it remains to be seen whether it'll work in 3.1.1. --Chuck Billinghurst, David (CRTS) wrote: I think you need to configure with --enable-nls \ --without-included-gettext \
Re: libiconv
On Thu, Jul 11, 2002 at 12:37:18PM +1000, Billinghurst, David (CRTS) wrote: I think you need to configure with --enable-nls \ --without-included-gettext \ Yup. I do. Maybe it's a cross-build thing. cgf For gcc-3.2 I get $ cygcheck cc1.exe Found: .\cc1.exe .\cc1.exe C:\cygwin\bin\cygwin1.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\NTDLL.DLL C:\cygwin\bin\cygintl-2.dll C:\cygwin\bin\cygiconv-2.dll $ cygcheck jc1.exe Found: .\jc1.exe .\jc1.exe C:\cygwin\bin\cygwin1.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\NTDLL.DLL C:\cygwin\bin\cygiconv-2.dll C:\cygwin\bin\cygintl-2.dll C:\cygwin\bin\cygz.dll Don't know if it works, but it passes the testsuites.
Re: libiconv
On Wed, Jul 10, 2002 at 10:41:17PM -0400, Charles Wilson wrote: It's worth a try, but wasn't there a lot of work done recently in the top-level configury of gcc? You are probably benefitting from that; it remains to be seen whether it'll work in 3.1.1. I think most of the work was just removing ancient cygnus-era targets and moving things around so they were grouped nicely. I didn't think there was much, if any, increased functionality. cgf
RE: libiconv
This all gets my vote, particularly libiconv. And as a bonus, it gives me yet another excuse to delay release of mutt-1.4-1 ;-) (it uses libiconv). -- Gary R. Van Sickle Brewer. Patriot. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Wilson Sent: Monday, June 24, 2002 4:50 PM To: [EMAIL PROTECTED] Subject: ITP: libiconv Okay, I've finished the multi-round rebuild of gettext and libiconv, and have six new packages ready for upload (don't worry; after approval I can handle the upload myself). However, since some are completely new packages, and others are updates that *depend* on the new packages, I can't upload any of them until the new packages are approved. So here goes... --Chuck NEW packages: libiconv-1.8-2 : contains most of the libiconv package libiconv2-1.8-2 : contains cygiconv-2.dll libcharset1-1.8-2: contains cygcharset-1.dll (*) libintl2-0.11.2-2: contains cygintl-2.dll (**) gettext-devel-0.11.2-2: contains development-oriented gettext utils, docs, import/static libs, etc. UPDATED packages: gettext-0.11.2-2: contains the core gettext utils docs OBSOLETED (but we'll keep them on the server because other progs need them): libintl1-0.10.40-1: contains cygintl-1.dll (*) It's not clear whether the API of libcharset and libiconv will always change simultaneously. It appears that libcharset is a separate, but included, project. So, to enable the two DLL's to be updated (e.g. version-bumped) separately, they need to each live in their own setup package. (**) cygintl-2.dll now depends on cygiconv-2.dll (and vice versa). Also, xgettext.exe (in the gettext-devel package) depends on cygexpat-0.dll. Plus, the internal API of the intl library changed. So, all of these taken together justify the bump of the DLL version number, and the new package 'libintl2'. The round-robin rebuild was: no libiconv installed built gettext-0.11.2-1 installed it built libiconv-1.8-1 (against the iconv-less gettext) installed it built gettext-0.11.2-2 (against the new iconv) installed it built libiconv-1.8-2 (against the iconv-ful gettext) installed it And it all seems to work. libiconv passes all of its tests. gettext passes most of its tests -- there are two failures that seem to be bugs in gettext's test suite itself, a number of failures that boil down to pathname differences in the expected output (e.g. not really failures), and then 18 failures that all have to do with testing proper -rpath functionality. But we don't have -rpath on cygwin, so we really should just skip these tests. Packages available at: http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/release/ in the following tree: gettext/ gettext/gettext-devel/ gettext/libintl2/ libiconv/ libiconv/libiconv2/ libiconv/libcharset1/ The setup.hints: GETTEXT: sdesc: GNU Internationalization library and core utilities ldesc: The GNU gettext package provides a set of tools and documentation for producing multi-lingual messages in programs. Tools include a set of conventions about how programs should be written to support message catalogs, a directory and file naming organization for the message catalogs, a runtime library which supports the retrieval of translated messages, and stand-alone programs for handling the translatable and the already translated strings. Gettext provides an easy to use library and tools for creating, using, and modifying natural language catalogs and is a powerful and simple method for internationalizing programs. category: Devel Libs requires: cygwin libintl2 libiconv2 GETTEXT-DEVEL: sdesc: GNU Internationalization development utilities ldesc: The GNU gettext package provides a set of tools and documentation for producing multi-lingual messages in programs. Tools include a set of conventions about how programs should be written to support message catalogs, a directory and file naming organization for the message catalogs, a runtime library which supports the retrieval of translated messages, and stand-alone programs for handling the translatable and the already translated strings. Gettext provides an easy to use library and tools for creating, using, and modifying natural language catalogs and is a powerful and simple method for internationalizing programs. category: Devel requires: cygwin libintl2 gettext texinfo libiconv2 expat external-source: gettext LIBINTL2: sdesc: GNU Internationalization runtime library ldesc: The GNU gettext package provides a set of tools and documentation for producing multi-lingual messages in programs. Tools include a set of conventions about how programs should be written to support message catalogs, a directory and file naming organization for the message catalogs, a runtime library which supports the retrieval of translated messages, and stand-alone programs
RE: libiconv
ditto for ImageMagick (it uses it too, and I could use an excuse). -Original Message- From: Gary R. Van Sickle [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 25 June 2002 10:42 To: [EMAIL PROTECTED] Subject: RE: libiconv This all gets my vote, particularly libiconv. And as a bonus, it gives me yet another excuse to delay release of mutt-1.4-1 ;-) (it uses libiconv).
Re: libiconv
Christopher Faylor wrote: On Tue, Jun 25, 2002 at 10:49:57AM +1000, Billinghurst, David (CRTS) wrote: ditto for ImageMagick (it uses it too, and I could use an excuse). I don't think there is any doubt that this will be useful. I'd say go for it, Chuck. Okay, it's uploaded. Announcement after a while. --Chuck
RE: libiconv
Christopher Faylor wrote: On Tue, Jun 25, 2002 at 10:49:57AM +1000, Billinghurst, David (CRTS) wrote: ditto for ImageMagick (it uses it too, and I could use an excuse). I don't think there is any doubt that this will be useful. I'd say go for it, Chuck. Okay, it's uploaded. Announcement after a while. Dang, there goes our excuse. ;-) -- Gary R. Van Sickle Brewer. Patriot.
