compiling mutt 1.5.19 on Solaris 10: iconv errors
Hi, I can't figure out why I have the following errors when I am using libiconv 1.12. Pls help! : checking iconv.h usability... yes checking iconv.h presence... yes checking for iconv.h... yes checking whether iconv.h defines iconv_t... yes checking whether this iconv is good enough... no configure: error: Try using libiconv instead
Re: compiling mutt 1.5.19 on Solaris 10: iconv errors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday, April 12 at 08:49 PM, quoth June Qiu: I can't figure out why I have the following errors when I am using libiconv 1.12. Pls help! : checking iconv.h usability... yes checking iconv.h presence... yes checking for iconv.h... yes checking whether iconv.h defines iconv_t... yes checking whether this iconv is good enough... no configure: error: Try using libiconv instead The exact compilation details will be in your config.log file (you probably aren't actually *using* the libiconv you installed). Essentially, that is good enough test is checking whether iconv will convert from UTF-8 to UTF-8 (which *SHOULD* be a no-brainer, but is broken in some iconv implementations). ~Kyle - -- It has been my experience that folks who have no vices have very few virtues. -- Abraham Lincoln -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkniwFEACgkQBkIOoMqOI17VMgCfc2c8PcdybBrG1ixcYjtxr510 XH8An3+5q8gyw5T1Jl3CDQ6yXA5+RHXN =zlNr -END PGP SIGNATURE-
Re: iconv stuff on solaris still unresolved
Hello Sven, On Sunday, October 13, 2002 at 12:52:14 AM +0200, Sven Guckes wrote: this iconv stuff just doesn't work on solaris. I don't understand the problem: Quick scanning your mails here since July shows you sometimes quote and write accented chars correctly, and sometimes not. Noted that's never good in your attribution lines, appart this one for Ren (hand typed e acute?). You use different builds of Mutt, or different setups, right? i downloaded the latest iconv lib and installed it, recompiled mutt --with-iconv=$HOME That's not always enough on systems having their own integrated iconv functions. Can you confirm it's linked with $HOME/lib/libiconv.so.2 using something equivalent to ldd or chatr for Solaris? Otherwise you could try to play with export LDFLAGS=-L$HOME/lib before configure. | $ ldd /usr/local/bin/mutt | libncurses.so.5 = /usr/local/lib/libncurses.so.5 | libiconv.so.2 = /usr/local/lib/libiconv.so.2 | libc.so.5 = /lib/libc.so.5 but no go. this *really* bugs me, too... *grr* What's your terminal, it's charset, your $charset and locale? Here is a test CP-850 n tilde (164 A4): ¤ Please describe what you see in pager, and when piped to less. And quote it back. On Sunday, October 13, 2002 at 1:12:59 AM +0200, Sven Guckes wrote: the solaris admin chose to install only the language stuff for C - and no others... You mean locale C/POSIX? This would be a problem too... But you can install a private locale in $HOME: find source files (locales and charsets), build a choosen one giving a destination in $HOME, and use it in $LANG/$LC_* with absolute path. Like: | $ localedef -i de_DE -f ISO-8859-1 $HOME/de_DE | Computing table size for character classes might take a while... done | Computing table size for collation information might take a while... done | | $ ls -ld $HOME/de_DE | drwxr-xr-x 2 alainalain1024 Oct 15 02:21 /home/alain/de_DE/ | | $ LC_ALL=$HOME/de_DE checklocale | [...] | current settings: | LC_ALL = /home/alain/de_DE | LANG= fr_FR.cp-1252@euro | LC_MESSAGES = C | LC_COLLATE = C | | Overriding all locale categories with LC_ALL succeeded. | [...snip perfect ISO isprint() table...] Note I cheated: A bug here (libc5) makes this doesn't work as standard say. I had to use the relative path ../../..$HOME/de_DE really (3 levels up from /usr/share/locale). Bye!Alain.
Re: iconv stuff on solaris still unresolved
* On 2002.10.13, in [EMAIL PROTECTED], * Sven Dogbert Guckes [EMAIL PROTECTED] wrote: so - what *is* required then? I don't know: I install Solaris (with all the language options), I compile mutt. Mutt works. well - +HAVE_ICONV, for sure. but is +ICONV_NONTRANS? what? I don't know. Do you want me to find out what ICONV_NONTRANS is and report back? I only pasted it because you did, and I figured you'd be irritated if I didn't include mine. You don't really have room to be snotty today. Today it's *your* problem that someone else is trying to contribute information to. besides, you did not specify the kind of solaris you use. No, I didn't. I probably should have, but neglected to because I've had success on all recent revs -- some minor issues on 7, but it works perfectly on 8, which is what you use. No trouble along these lines on 9 beta, either. I haven't upgraded to 9 FCS yet. I'll add that I don't have any particularly strange libraries linked. The usual Sun base and networking libraries, libgen for regexes. I suppose you might not have libintl (mine does, of course), but that would be very strange on your side. Sven, if you have a question, please ask. But don't get irritable because I didn't dissect my installation to find out why yours doesn't work. Perhaps you should post your configure output, or mail it to me directly. I'd be glad to look over it, if you like. -- -D.We establised a fine coffee. What everybody can say Sun Project, APC/UCCO TASTY! It's fresh, so-mild, with some special coffee's University of Chicago bitter and sourtaste. LET'S HAVE SUCH A COFFEE! NOW! [EMAIL PROTECTED] Please love CAFE MIAMI. Many thanks.
RE: iconv stuff on solaris still unresolved
I recently installed mutt (1.4) on a number of solaris machines: sol7 and sol8. I needed libiconv and I certainly had to be root, regardless of my target. It was not a simple install but it did work reliably once I did the configure correctly per below: I first set LD_RUN_PATH and LD_LIBRARY_PATH to /usr/local/lib ./configure --disable-nls --enable-buffy --enable-locales-fix --enable-pop - -with-regex --prefix=. I guess the with-regex is sort of critical for solaris. Hope this helps. john -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Champion Sent: Tuesday, 15 October 2002 02:34 To: [EMAIL PROTECTED] Subject: Re: iconv stuff on solaris still unresolved * On 2002.10.13, in [EMAIL PROTECTED], * Sven Dogbert Guckes [EMAIL PROTECTED] wrote: so - what *is* required then? I don't know: I install Solaris (with all the language options), I compile mutt. Mutt works. well - +HAVE_ICONV, for sure. but is +ICONV_NONTRANS? what? I don't know. Do you want me to find out what ICONV_NONTRANS is and report back? I only pasted it because you did, and I figured you'd be irritated if I didn't include mine. You don't really have room to be snotty today. Today it's *your* problem that someone else is trying to contribute information to. besides, you did not specify the kind of solaris you use. No, I didn't. I probably should have, but neglected to because I've had success on all recent revs -- some minor issues on 7, but it works perfectly on 8, which is what you use. No trouble along these lines on 9 beta, either. I haven't upgraded to 9 FCS yet. I'll add that I don't have any particularly strange libraries linked. The usual Sun base and networking libraries, libgen for regexes. I suppose you might not have libintl (mine does, of course), but that would be very strange on your side. Sven, if you have a question, please ask. But don't get irritable because I didn't dissect my installation to find out why yours doesn't work. Perhaps you should post your configure output, or mail it to me directly. I'd be glad to look over it, if you like. -- -D.We establised a fine coffee. What everybody can say Sun Project, APC/UCCO TASTY! It's fresh, so-mild, with some special coffee's University of Chicago bitter and sourtaste. LET'S HAVE SUCH A COFFEE! NOW! [EMAIL PROTECTED] Please love CAFE MIAMI. Many thanks.
Re: iconv stuff on solaris still unresolved
* René Clerc [EMAIL PROTECTED] [2002-10-12 16:46]: * Sven Guckes [EMAIL PROTECTED] [11-10-2002 20:25]: [all context] * Ren Clerc [EMAIL PROTECTED] [2002-10-11 16:01]: ^^ This grieves me, Sven... sorry, man. this iconv stuff just doesn't work on solaris. i downloaded the latest iconv lib and installed it, recompiled mutt --with-iconv=$HOME - but no go. this *really* bugs me, too... *grr* Sven
Re: iconv stuff on solaris still unresolved
* Piotr Kasztelowicz [EMAIL PROTECTED] [2002-10-12 23:04]: On Sun, 13 Oct 2002, Sven Guckes wrote: and installed it, recompiled mutt --with-iconv=$HOME - it can be. I have like you experiences with mutt, iconv, Solaris 7, gcc 3.2 and gnumake so that makes two of us. well, i suppose i might be related because technically we use different versions: system: SunOS 5.8 Generic_108528-13 sun4u sparc programs: libiconv 1.8, gcc 2.95.3, GNU make 3.77, mutt 1.4 + ncurses 5.2 + +HAVE_ICONV -ICONV_NONTRANS so - is anyone using mutt 1.4 with iconv on solaris successfully? mind you - i am not root, so all my stuff resides in my $HOME. i once tried to resolve this but i think the bottom line was that it all is of no use because the solaris admin chose to install only the language stuff for C - and no others... Sven === $ ls -l libiconv-1.8.tar.gz .. 3514117 May 29 19:46 libiconv-1.8.tar.gz $ gcc --version 2.95.3 $ make --version GNU Make version 3.77.. $ mutt -v Mutt 1.4i (2002-05-29) ... System: SunOS 5.8 (sun4u) [using ncurses 5.2] Compile options: ... +HAVE_ICONV -ICONV_NONTRANS $ uname -a SunOS ritz 5.8 Generic_108528-13 sun4u sparc
Re: iconv stuff on solaris still unresolved
* On 2002.10.12, in [EMAIL PROTECTED], * Sven Dogbert Guckes [EMAIL PROTECTED] wrote: so - is anyone using mutt 1.4 with iconv on solaris successfully? mind you - i am not root, so all my stuff resides in my $HOME. I'm using 1.5.1 on Solaris, and before that I used 1.3.x on Solaris, all successfully. I use the native iconv, though, not libiconv. I didn't do anything special; it just worked. +HAVE_ICONV +ICONV_NONTRANS +HAVE_GETSID +HAVE_GETADDRINFO I've built 1.4 on Solaris with no trouble, but I don't regularly use it. i once tried to resolve this but i think the bottom line was that it all is of no use because the solaris admin chose to install only the language stuff for C - and no others... Well, that would be a problem. But it's not fair or correct to say that this iconv stuff just doesn't work on Solaris. -- -D.We establised a fine coffee. What everybody can say Sun Project, APC/UCCO TASTY! It's fresh, so-mild, with some special coffee's University of Chicago bitter and sourtaste. LET'S HAVE SUCH A COFFEE! NOW! [EMAIL PROTECTED] Please love CAFE MIAMI. Many thanks.
compile errors on macosx and disable-iconv
I'm having problems compiling mutt-1.4i on Mac OS X 10.2. I already discovered that --without-iconv doesn't work and have applied Lars' patch-1.4.lh.noiconv.1 patch (it says patch.1.3.28.lh.noiconv in the patched ChangeLog) that added --disable-iconv. BTW, the patched ChangeLog also says no m4 files are modified, but running the patch did touch iconv.m4: patching file INSTALL patching file PATCHES patching file charset.h patching file configure.in patching file m4/iconv.m4 Anyways, I did a configure --disable-iconv and got no errors. On the make, here's the output: bash-2.05a$ make cd . aclocal -I m4 cd . automake --foreign --include-deps Makefile ./gen_defs ./OPS ./OPS.PGP keymap_defs.h ./patchlist.sh ./PATCHES patchlist.c cd . \ CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh ./config.status creating Makefile Makefile:450: *** missing separator. Stop. First, why is the Makefile being modified during a make??? Second, starting at line 450, there's a bunch of macros that didn't appear to be processed (output below). Any suggestions are welcome. Or should I go with mutt-1.5? I'm not on mutt-devel. If this is a big problem, could someone forward this message there? Thanks. @AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/regex.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/snprintf.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/strcasecmp.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/strdup.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/account.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/addrbook.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/alias.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ascii.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/attach.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/base64.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/browser.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/buffy.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/charset.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/color.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/commands.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/complete.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/compose.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/copy.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/curs_lib.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/curs_main.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/date.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/dotlock.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/edit.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/editmsg.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/enter.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/extlib.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/filter.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/flags.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/from.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/getdomain.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gnupgparse.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/handler.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/hash.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/hdrline.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/headers.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/help.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/history.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/hook.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/init.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/keymap.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/lib.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/main.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/makedoc.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/mbox.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/mbyte.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/md5c.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/menu.Po@am__quote
Re: compile errors on macosx and disable-iconv
On Fri, Sep 13, 2002 at 02:19:49AM -0700, Eugene Lee wrote: : : I'm having problems compiling mutt-1.4i on Mac OS X 10.2. I already : discovered that --without-iconv doesn't work and have applied Lars' : patch-1.4.lh.noiconv.1 patch (it says patch.1.3.28.lh.noiconv in the : patched ChangeLog) that added --disable-iconv. [...] I had a short burst of exchanges with Lars Heckling, and he helped me to resolve the problem. If anyone needs Mutt sans the recommended libiconv support, feel free to bug me for the update. Thanks Lars! Hmmm, is there an update planned for mutt-1.4 in the near future? -- Eugene Lee [EMAIL PROTECTED]
--with-iconv?
I just built 1.4 just fine, but am curious about something. I used --with-iconv in configure, and it didn't find everything it needed, and make failed. Using --with-libiconv worked as it did in all the 1.3.x I have built. The reason I used --with-iconv was because that is the only reference to iconv in configure --help. Is this intentional or an oversight? -Ken
Weird bug while compiling 1.4i with iconv 1.8
Hi, everybody! While running configure script it finds iconv.h Determines that type iconv_t is defined. But never finds declaration for iconv function... libiconv from ftp.gnu.org was installed ok. Gettext from the same place compiled great with libiconv. BTW There was no internal system support for icnv functions. If someone has a hint for me, please let me know about it. Thanks in advance. -- Eugene Paskevich | *==(--- | Plug me into [EMAIL PROTECTED]| ---)==* | The Matrix Public PGP key:mailto:[EMAIL PROTECTED]?subject=publicpgpkey Fingerprint: 03 BE 52 C8 41 8C 10 DC 2F 81 A2 21 28 5E D3 12
Re: charset-hook / iconv-hook
On 2002-05-31 10:22:56 +0100, Edmund GRIMLEY EVANS wrote: Now, I don't really understand why charset-hooks are being used AT ALL for sending messages, now that iconv-hook is available, so I am suggesting the attached patch, hoping that people who use charset-hook can tell me if it makes sense. That patch looks correct to me. -- Thomas Roessler[EMAIL PROTECTED]
Re: 1.3.28: still not possible to compile without iconv
begin quoting what Claus Assmann said on Sun, Mar 17, 2002 at 04:02:53PM -0800: I asked about this when 1.3.25 came out and got the answer that this should be fixed / will be looking into it. However, 1.3.28 still can't be configured without iconv. Any chance for a change? Pardon my ignorance, but why would you want to? msg25672/pgp0.pgp Description: PGP signature
Re: 1.3.28: still not possible to compile without iconv
Shawn -- ...and then Shawn McMahon said... % % begin quoting what Claus Assmann said on Sun, Mar 17, 2002 at 04:02:53PM -0800: % I asked about this when 1.3.25 came out and got the answer that % this should be fixed / will be looking into it. However, 1.3.28 % still can't be configured without iconv. Any chance for a change? % % Pardon my ignorance, but why would you want to? It's not that he wants to; it's that it has the problem. He does not have iconv and thus can't get his mutt to play. :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! msg25675/pgp0.pgp Description: PGP signature
1.3.28: still not possible to compile without iconv
I asked about this when 1.3.25 came out and got the answer that this should be fixed / will be looking into it. However, 1.3.28 still can't be configured without iconv. Any chance for a change? I've attached a patch that seems to work. It's a bit of hack, a clean solution would be to have an iconv.h substitute that defines the prototypes of the replacement functions which are in charset.c and also defines iconv_t and EILSEQ. This would localize the changes instead of spreading them out over many files. diff -c -r mutt-1.3.28/charset.c mutt-1.3.28-/charset.c *** mutt-1.3.28/charset.c Tue Jan 22 17:02:39 2002 --- mutt-1.3.28-/charset.c Sun Mar 17 15:53:57 2002 *** *** 31,37 --- 31,39 #include unistd.h #include errno.h + #ifdef HAVE_ICONV #include iconv.h + #endif #include mutt.h #include charset.h diff -c -r mutt-1.3.28/charset.h mutt-1.3.28-/charset.h *** mutt-1.3.28/charset.h Tue Feb 13 14:06:14 2001 --- mutt-1.3.28-/charset.h Sun Mar 17 15:46:58 2002 *** *** 19,25 --- 19,29 #ifndef _CHARSET_H #define _CHARSET_H + #if HAVE_ICONV #include iconv.h + #else + #define iconv_t int + #endif int mutt_convert_string (char **, const char *, const char *, int); diff -c -r mutt-1.3.28/gnupgparse.c mutt-1.3.28-/gnupgparse.c *** mutt-1.3.28/gnupgparse.cWed Aug 1 07:06:58 2001 --- mutt-1.3.28-/gnupgparse.c Sun Mar 17 15:54:48 2002 *** *** 44,50 --- 44,52 #include mutt.h #include pgp.h #include charset.h + #ifdef HAVE_ICONV #include iconv.h + #endif /* for hexval */ #include mime.h diff -c -r mutt-1.3.28/rfc2047.c mutt-1.3.28-/rfc2047.c *** mutt-1.3.28/rfc2047.c Mon Oct 15 13:18:32 2001 --- mutt-1.3.28-/rfc2047.c Sun Mar 17 15:50:10 2002 *** *** 24,30 --- 24,32 #include ctype.h #include errno.h + #if HAVE_ICONV #include iconv.h + #endif #include stdio.h #include stdlib.h #include string.h diff -c -r mutt-1.3.28/sendlib.c mutt-1.3.28-/sendlib.c *** mutt-1.3.28/sendlib.c Wed Nov 7 02:51:29 2001 --- mutt-1.3.28-/sendlib.c Sun Mar 17 15:53:39 2002 *** *** 649,654 --- 649,657 } /* Define as 1 if iconv sometimes returns -1(EILSEQ) instead of transcribing. */ + #ifndef EILSEQ + # define EILSEQ EINVAL + #endif #define BUGGY_ICONV 1 /*
Re: 1.3.28: still not possible to compile without iconv
* On 2002.03.17, in [EMAIL PROTECTED], * Claus Assmann [EMAIL PROTECTED] wrote: I asked about this when 1.3.25 came out and got the answer that this should be fixed / will be looking into it. However, 1.3.28 still can't be configured without iconv. Any chance for a change? Lars Hecking posted a patch to mutt-dev over a month ago. It's still awaiting testers before it can be merged into the tree for 1.4. It seems to work for him, but very few truly iconv-less people have tried it and reported back. See http://groups.yahoo.com/group/mutt-dev/message/13851 -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: 1.3.28: still not possible to compile without iconv
On Sun, Mar 17, 2002, David Champion wrote: * On 2002.03.17, in [EMAIL PROTECTED], * Claus Assmann wrote: I asked about this when 1.3.25 came out and got the answer that this should be fixed / will be looking into it. However, 1.3.28 still can't be configured without iconv. Any chance for a change? Lars Hecking posted a patch to mutt-dev over a month ago. It's still awaiting testers before it can be merged into the tree for 1.4. It seems to work for him, but very few truly iconv-less people have tried it and reported back. See http://groups.yahoo.com/group/mutt-dev/message/13851 Thanks, I found the message in a different archive (groups.yahoo.com wants cookies...) Feedback: it compiles fine on my machine (OpenBSD 2.8) and it seems to work (only basic testing). So please merge it before 1.4. Thanks! (sorry, I don't read mutt-dev anymore, I'm getting more than 500 mails a day (obviously I can only skim through the subjects and read only a subset...))
Re: 1.3.28: still not possible to compile without iconv
* On 2002.03.17, in [EMAIL PROTECTED], * Claus Assmann [EMAIL PROTECTED] wrote: (sorry, I don't read mutt-dev anymore, I'm getting more than 500 mails a day (obviously I can only skim through the subjects and read only a subset...)) Lars doesn't read mutt-users anymore for the same kind of reason, so that makes a problem. :) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Fwd: [Patch] 1.3.x without iconv
There have been various comments here by people attempting to move from the 1.2.x tree to the 1.3.x tree about the new iconv requirement, and the fact that the --without-libiconv option documented in INSTALL does not actually work. Lars Hecking posted the attached message patch to mutt-dev as part of an attempt to get this resolved by 1.4, but it needs testing. I'm reposting it here so it can hopefully get some more, since most of the -dev crowd already resolved this by having a good enough iconv locally. If you have problems or comments related to this patch please post them back to mutt-dev. ---BeginMessage--- See attached. Warning: this is a HACK, no matter how ingeniously executed. It allows to compile mutt-1.3.27 without iconv support, and it does just that. I cannot guarantee and haven't tested that a patched mutt performs correctly in every respect, only made it compile. These changes should go into cvs/distribution, they are independent of the rest: * charset.c, gnupgparse.c, rfc2047.c: don't #include iconv.h, charset.h already does it * init.h: conditionalise iconv-hook for HAVE_ICONV (fair enough, no?) These changes should no go into cvs/distribution, on account of being an untested hack: * charset.h: conditionalise iconv.h inclusion for HAVE_ICONV_H; add iconv_t definition, and prototypes for iconv_open(), iconv() iconv_close() if there is no system iconv(); mutt's iconv functions already have fallbacks if no system iconv is available, but we still need the prototypes/typedef to get everything compiled in the first place * configure.in: add check for iconv.h; add check for iconv_t; emit a warning rather than an error if iconv is not found * sendlib.c: let convert_file_to() always fail with -1 if iconv() is not available === * m4/iconv.m4: change --with-libiconv-prefix=DIR to --with-iconv[=DIR] and check for no; this makes configure compatible to INSTALL :) Caveat: this change makes MUTT_AM_ICONV totally incompatible with (but also better than ;) AM_ICONV. That's the main reason I don't want this in cvs or distribution, I would like to see the generic AM_ICONV changed to do something useful. === No auto* generated files included. patch-1.3.27.lh.noiconv.1.gz Description: application/gunzip ---End Message--- msg24452/pgp0.pgp Description: PGP signature
Iconv question
I just built and installed Mutt 1.3.27i. I have iconv in my C library with all MIME character set names supported. I'm running mutt in a UTF-8 xterm with my LC_* variables all set to en_US.utf8. Given this setup and the new iconv support, my expectation was that when I displayed a Latin-1 message (marked as such in the Content-Type: header via charset=ISO-8859-1) mutt would convert it from Latin-1 to UTF-8 so it would display properly in my terminal window. But it's not doing so - it's just outputting the bytes from the message with no conversion. Could anyone tell me what I'm missing? Thanks! -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW1032C | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754 -- Every path has its puddle.
--without-iconv doesn't work?
System: OpenBSD 2.8
./configure --without-iconv
doesn't work:
checking for catalogs to be installed... de ru it es uk fr pl nl cs id sk ko el zh_TW
zh_CN pt_BR eo gl sv da lt tr ja hu et ca
configure: error: Unable to find an iconv function. See INSTALL for help
I read the INSTALL file, that's why I used
--without-iconv
BTW:
http://clisp.cons.org/~haible/packages-libiconv.html
gives 404.
Before you yell at me: I found the package (later on there is
an ftp URL).
So which part of the INSTALL file is correct: must I install
yet another library or is there a way to turn iconv off?
According to these lines in configure:
if test $am_cv_func_iconv != yes
then
{ echo configure: error: Unable to find an iconv function. See INSTALL for help
12; exit 1; }
fi
it's not possible to be turned off...
Re: --without-iconv doesn't work?
This is annoying. I've successfully compiled mutt without iconv by
commenting out lines in config.h, so I think that this is just a
braindead policy decision. Try commenting out the iconv test you quoted
below in configure, and see what happens when you configure and build
without iconv. Also note that for some reason the iconv macro is
defined twice in config.h: perhaps one of them is hardwired. So make
sure they're both gone, and remove them if they're not, before you
build. Let us know what happens -- I definitely think that mutt should
be able to compile without iconv on old boxes where users don't need the
functionality.
-Daniel
On Wed, Jan 02, 2002 at 07:20:14AM -0800, Claus Assmann [EMAIL PROTECTED] wrote:
System: OpenBSD 2.8
./configure --without-iconv
doesn't work:
checking for catalogs to be installed... de ru it es uk fr pl nl cs id sk ko el
zh_TW zh_CN pt_BR eo gl sv da lt tr ja hu et ca
configure: error: Unable to find an iconv function. See INSTALL for help
I read the INSTALL file, that's why I used
--without-iconv
BTW:
http://clisp.cons.org/~haible/packages-libiconv.html
gives 404.
Before you yell at me: I found the package (later on there is
an ftp URL).
So which part of the INSTALL file is correct: must I install
yet another library or is there a way to turn iconv off?
According to these lines in configure:
if test $am_cv_func_iconv != yes
then
{ echo configure: error: Unable to find an iconv function. See INSTALL for help
12; exit 1; }
fi
it's not possible to be turned off...
--
Daniel E. Eisenbud
[EMAIL PROTECTED]
We should go forth on the shortest walk perchance, in the spirit of
undying adventure, never to return,--prepared to send back our embalmed
hearts only as relics to our desolate kingdoms.
--Henry David Thoreau, Walking
Re: --without-iconv doesn't work?
without iconv. Also note that for some reason the iconv macro is defined twice in config.h: perhaps one of them is hardwired. So make The reason is that the definition in acconfig.h is superfluous. At a glance, it seems that about 20 definitions in acconfig.h are superfluous. (See Making `configure' Scripts in the autoconf manual for how config.h gets generated).
Re: --without-iconv doesn't work?
On Wed, Jan 02, 2002 at 07:20:14AM -0800, Claus Assmann wrote: System: OpenBSD 2.8 ./configure --without-iconv doesn't work: checking for catalogs to be installed... de ru it es uk fr pl nl cs id sk ko el zh_TW zh_CN pt_BR eo gl sv da lt tr ja hu et ca configure: error: Unable to find an iconv function. See INSTALL for help I read the INSTALL file, that's why I used --without-iconv BTW: http://clisp.cons.org/~haible/packages-libiconv.html gives 404. The URL should be http://www.gnu.org/software/libiconv/ /magnus
Re: --without-iconv doesn't work?
On Wed, Jan 02, 2002, Daniel Eisenbud wrote: This is annoying. I've successfully compiled mutt without iconv by commenting out lines in config.h, so I think that this is just a braindead policy decision. Try commenting out the iconv test you quoted below in configure, and see what happens when you configure and build without iconv. Also note that for some reason the iconv macro is It fails in compilation (this is mutt-1.3.25). I started hacking to get around the missing iconv stuff, but there seems to be too much depending on it, e.g., charset.h includes iconv.h, if I change that to: #if HAVE_ICONV #include iconv.h #endif then it fails somewhere else: Making all in contrib gcc ... -DHAVE_CONFIG_H=1 -I. -I. -Iintl -I./intl -Wall -pedantic -g -O2 -c patchlist.c In file included from mutt.h:51, from patchlist.c:5: charset.h:28: syntax error before `mutt_iconv_open' charset.h:28: warning: type defaults to `int' in declaration of `mutt_iconv_open' charset.h:28: ANSI C forbids data definition with no type or storage class charset.h:29: syntax error before `const' In file included from mutt.h:812, from patchlist.c:5: protos.h:162: syntax error before `iconv_t' *** Error code 1 Does your system have the iconv.h file etc? Or did you change more than just config.h?
Re: --without-iconv doesn't work?
On Wed, Jan 02, 2002 at 08:29:08AM -0800, Claus Assmann [EMAIL PROTECTED] wrote: On Wed, Jan 02, 2002, Daniel Eisenbud wrote: This is annoying. I've successfully compiled mutt without iconv by commenting out lines in config.h, so I think that this is just a braindead policy decision. Try commenting out the iconv test you quoted below in configure, and see what happens when you configure and build without iconv. Also note that for some reason the iconv macro is It fails in compilation (this is mutt-1.3.25). I started hacking to get around the missing iconv stuff, but there seems to be too much depending on it, e.g., charset.h includes iconv.h, if I change that to: #if HAVE_ICONV #include iconv.h #endif [...] Does your system have the iconv.h file etc? Or did you change more than just config.h? My system does have iconv.h, which explains why it didn't fail. I think that this bug is well worth fixing before mutt 1.4. I'll look into it this afternoon. -Daniel -- Daniel E. Eisenbud [EMAIL PROTECTED] We should go forth on the shortest walk perchance, in the spirit of undying adventure, never to return,--prepared to send back our embalmed hearts only as relics to our desolate kingdoms. --Henry David Thoreau, Walking
Re: --without-iconv doesn't work?
Claus Assmann writes: System: OpenBSD 2.8 ./configure --without-iconv doesn't work: The documentation in INSTALL is wrong. There is no --without-iconv configure option, and configure does the right thing by bombing out. I think this can be fixed, though :)
Re: Problems with 1.3.22's iconv/libiconv
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Sep 24, 2001 at 06:37:02PM -0700, Will Yardley wrote: i don't know too much about this, but i was able to get over thie problem with some help from some developers on this list. i had to export LDFLAGS to something; in my case, this worked: LDFLAGS=-Wl,-R/usr/local/lib ./configure --with-domain=newdream.net --with-libiconv-prefix=/usr/local/lib Thanks. Reading your reply, I remembered the ld.so.conf file. I just added /opt/libiconv/lib to /etc/ld.so.conf and rand ldconfig. Works like a charm now. Thanks, js. - -- Jean-Sebastien Morisset, Sr. UNIX Administrator [EMAIL PROTECTED] Personal Homepage http://jsmoriss.mvlan.net/ This is Linux Country. On a quiet night you can hear Windows NT reboot! - please pgp encrypt all correspondence -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Personal Home Page http://jsmoriss.mvlan.net/ iD8DBQE7sIcpnGyIOcYaingRAivkAJ0SaRIHdla6YRhZyGxATlUPv5wALgCgjCZy 0D++VJKczlUFU6A9JW5HwHk= =SvFt -END PGP SIGNATURE-
Problems with 1.3.22's iconv/libiconv
Here's my configure: ./configure \ --prefix=/opt/mutt-1.3.22 \ --enable-pop --enable-imap \ --with-curses=/opt/ncurses \ --with-libiconv-prefix=/opt/libiconv \ --with-debug And the output: [snip!] checking for iconv... yes checking for iconv declaration... extern size_t iconv (iconv_t cd, const char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); [snip!] checking whether this iconv is good enough... no configure: error: Try using libiconv instead I've tried using --without-iconv, but it doesn't work. Any suggestions? BTW, anyone know where I can find the pgp-outlook patch for v1.3.22? Thanks, js. -- Jean-Sebastien Morisset, Sr. UNIX Administrator [EMAIL PROTECTED] Personal Homepage http://jsmoriss.mvlan.net/ This is Linux Country. On a quiet night you can hear Windows NT reboot! please pgp encrypt all correspondence PGP signature
Re: Problems with 1.3.22's iconv/libiconv
Jean-Sebastien Morisset wrote: checking whether this iconv is good enough... no configure: error: Try using libiconv instead i don't know too much about this, but i was able to get over thie problem with some help from some developers on this list. i had to export LDFLAGS to something; in my case, this worked: LDFLAGS=-Wl,-R/usr/local/lib ./configure --with-domain=newdream.net --with-libiconv-prefix=/usr/local/lib your mileage may vary of course. but you might try: LDFLAGS=-R/opt/libiconv ./configure --[etc] --with-libiconv-prefix=/opt/libiconv or LDFLAGS=-WI,R/opt/libiconv ./configure --[etc] --with-libiconv-prefix=/opt/libiconv if that doesn't work you might want to post more specifics of what OS, version, c compiler etc. you're using, and perhaps some of your config.log output. w -- GPG Public Key: http://infinitejazz.net/will/pgp/ PGP signature
Re: Problems with 1.3.22's iconv/libiconv
Jean-Sebastien -- ...and then Jean-Sebastien Morisset said... % ... % BTW, anyone know where I can find the pgp-outlook patch for v1.3.22? See http://mutt.sector13.org/mutt-build-cocktail for one... % % Thanks, % js. % -- % Jean-Sebastien Morisset, Sr. UNIX Administrator [EMAIL PROTECTED] % Personal Homepage http://jsmoriss.mvlan.net/ % This is Linux Country. On a quiet night you can hear Windows NT reboot! % please pgp encrypt all correspondence :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! PGP signature
iconv
another thing about iconv in INSTALL it says go to http://clisp.cons.org/~haible/packages-libiconv.html but i get 404 when i go to that webpage
Re: iconv
alexus mutt [06/09/01 18:37 -0400]: another thing about iconv in INSTALL it says go to http://clisp.cons.org/~haible/packages-libiconv.html but i get 404 when i go to that webpage Search google for (several) other download locations. -suresh
[william+mutt@hq.newdream.net: iconv etc]
woah - just as i was about to delete this message, i noticed that there are two User-Agent: headers. i accidentally responded off list at first, which bounced, and i then forwarded the resulting message to the list. mutt should remove the old User-Agent header though, right? From: Will Yardley [EMAIL PROTECTED] To: Mutt Users [EMAIL PROTECTED] Subject: iconv etc Date: Wed, 5 Sep 2001 05:19:41 -0700 User-Agent: Mutt/1.3.22.1i User-Agent: Mutt/1.3.22.1i Message-ID: [EMAIL PROTECTED] in the actual meessage file: Received: by mail.hq.newdream.net (Postfix, from userid 1012) id 405103B37D; Wed, 5 Sep 2001 05:19:41 -0700 (PDT) Date: Wed, 5 Sep 2001 05:19:41 -0700 From: Will Yardley [EMAIL PROTECTED] To: Mutt Users [EMAIL PROTECTED] Subject: iconv etc Message-ID: [EMAIL PROTECTED] Mail-Followup-To: Mutt Users [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=QTprm0S8XgL7H0Dt Content-Disposition: inline User-Agent: Mutt/1.3.22.1i User-Agent: Mutt/1.3.22.1i Sender: [EMAIL PROTECTED] Precedence: bulk Lines: 140 in my sent-mail folder: From: Will Yardley [EMAIL PROTECTED] To: Lars Hecking [EMAIL PROTECTED] Subject: Re: [[EMAIL PROTECTED]: Undelivered Mail Returned to Sender] Date: Wed, 5 Sep 2001 05:18:13 -0700 User-Agent: Mutt/1.3.22.1i Message-ID: [EMAIL PROTECTED] same message-id, same message From: Will Yardley [EMAIL PROTECTED] To: Mutt Users [EMAIL PROTECTED] Subject: Re: iconv etc Date: Wed, 5 Sep 2001 05:47:52 -0700 User-Agent: Mutt/1.3.22.1i Message-ID: [EMAIL PROTECTED] -w -- Sintax error in config file! (line 378) aborted! PGP Public Key: http://infinitejazz.net/will/pgp/
iconv etc
Lars Hecking wrote:
checking whether this iconv is good enough... no
configure: error: Try using libiconv instead
Strange - everything else looks correct.
We'll need the relevant parts of your config.log, too.
ok. i'll include what seems to be relevant in an attached text file.
i can send the whole file to anyone masochistic enough to want it.
the end of the file is the end of the config.log as well
-will
--
Sintax error in config file! (line 378)
aborted!
PGP Public Key:
http://infinitejazz.net/will/pgp/
; return 0; }
configure:6558: checking for iconv
configure:6576: gcc -o conftest -Wall -pedantic -g -O2 -I/home/will//include
-I/home/will/include -L/home/will//lib -L/home/will/lib conftest.c 15
/tmp/cca149331.o: In function `main':
/home/will/mutt-1.3.22.1/configure:6570: undefined reference to `libiconv_open'
/home/will/mutt-1.3.22.1/configure:6571: undefined reference to `libiconv'
/home/will/mutt-1.3.22.1/configure:6572: undefined reference to `libiconv_close'
configure: failed program was:
#line 6566 configure
#include confdefs.h
#include stdlib.h
#include iconv.h
int main() {
iconv_t cd = iconv_open(,);
iconv(cd,NULL,NULL,NULL,NULL);
iconv_close(cd);
; return 0; }
configure:6598: gcc -o conftest -Wall -pedantic -g -O2 -I/home/will//include
-I/home/will/include -L/home/will//lib -L/home/will/lib conftest.c -liconv 15
configure:6619: checking for iconv declaration
configure:6644: gcc -c -Wall -pedantic -g -O2 -I/home/will//include
-I/home/will/include conftest.c 15
configure:6634: conflicting types for `libiconv'
/home/will//include/iconv.h:82: previous declaration of `libiconv'
configure: failed program was:
#line 6625 configure
#include confdefs.h
#include stdlib.h
#include iconv.h
extern
#ifdef __cplusplus
C
#endif
#if defined(__STDC__) || defined(__cplusplus)
size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t
*outbytesleft);
#else
size_t iconv();
#endif
int main() {
; return 0; }
configure:6673: checking for nl_langinfo and CODESET
configure:6685: gcc -o conftest -Wall -pedantic -g -O2 -I/home/will//include
-I/home/will/include -L/home/will//lib -L/home/will/lib conftest.c 15
configure: In function `main':
configure:6681: `CODESET' undeclared (first use this function)
configure:6681: (Each undeclared identifier is reported only once
configure:6681: for each function it appears in.)
configure:6681: warning: unused variable `cs'
configure: failed program was:
#line 6678 configure
#include confdefs.h
#include langinfo.h
int main() {
char* cs = nl_langinfo(CODESET);
; return 0; }
configure:6708: checking for LC_MESSAGES
configure:6720: gcc -o conftest -Wall -pedantic -g -O2 -I/home/will//include
-I/home/will/include -L/home/will//lib -L/home/will/lib conftest.c 15
configure:6741: checking whether NLS is requested
configure:6763: checking whether included gettext is requested
configure:6783: checking for libintl.h
configure:6793: gcc -E -I/home/will//include -I/home/will/include conftest.c
/dev/null 2conftest.out
configure:6810: checking for GNU gettext in libc
configure:6824: gcc -o conftest -Wall -pedantic -g -O2 -I/home/will//include
-I/home/will/include -L/home/will//lib -L/home/will/lib conftest.c 15
/tmp/cca150081.o: In function `main':
/home/will/mutt-1.3.22.1/configure:6819: undefined reference to `bindtextdomain'
/home/will/mutt-1.3.22.1/configure:6820: undefined reference to `gettext'
/home/will/mutt-1.3.22.1/configure:6820: undefined reference to `_nl_msg_cat_cntr'
configure: failed program was:
#line 6815 configure
#include confdefs.h
#include libintl.h
extern int _nl_msg_cat_cntr;
int main() {
bindtextdomain (, );
return (int) gettext () + _nl_msg_cat_cntr
; return 0; }
configure:6840: checking for GNU gettext in libintl
configure:6856: gcc -o conftest -Wall -pedantic -g -O2 -I/home/will//include
-I/home/will/include -L/home/will//lib -L/home/will/lib conftest.c -lintl -liconv
15
configure:6889: checking for dcgettext
configure:6917: gcc -o conftest -Wall -pedantic -g -O2 -I/home/will//include
-I/home/will/include -L/home/will//lib -L/home/will/lib conftest.c -lintl -liconv
15
configure:6946: checking for msgfmt
configure:6980: checking for gmsgfmt
configure:7018: checking for xgettext
configure:7200: checking for bison
configure:7233: checking version of bison
configure:7281: checking for catalogs to be installed
configure:7326: checking whether this iconv is good enough
configure:7354: gcc -o conftest -Wall -pedantic -g -O2 -I/home/will//include
-I/home/will/include -L/home/will//lib -L/home/will/lib conftest.c -liconv 15
configure: failed program was:
#line 7336 configure
#include confdefs.h
#include iconv.h
int main()
{
iconv_t cd;
char buf[4];
char *ob;
size_t obl;
ob = buf, obl = sizeof(buf);
return ((cd = iconv_open(UTF-8, UTF-8)) != (iconv_t)(-1)
(iconv(cd, 0, 0, ob, obl) ||
!(ob == buf obl == sizeof(buf)) ||
iconv_close
Re: iconv etc
configure:6558: checking for iconv configure:6576: gcc -o conftest -Wall -pedantic -g -O2 -I/home/will//include -I/home/will/include -L/home/will//lib -L/home/will/lib conftest.c 15 /tmp/cca149331.o: In function `main': /home/will/mutt-1.3.22.1/configure:6570: undefined reference to `libiconv_open' /home/will/mutt-1.3.22.1/configure:6571: undefined reference to `libiconv' /home/will/mutt-1.3.22.1/configure:6572: undefined reference to `libiconv_close' Ok. You probably need to run configure as $ LDFLAGS=-R/home/will/lib ./configure ... (or LDFLAGS=-rpath /home/will/lib ..., I don't know which syntax your ld uses.) configure:6644: gcc -c -Wall -pedantic -g -O2 -I/home/will//include -I/home/will/include conftest.c 15 configure:6634: conflicting types for `libiconv' /home/will//include/iconv.h:82: previous declaration of `libiconv' Very strange. I have no explanation for this. configure:7326: checking whether this iconv is good enough configure:7354: gcc -o conftest -Wall -pedantic -g -O2 -I/home/will//include -I/home/will/include -L/home/will//lib -L/home/will/lib conftest.c -liconv 15 configure: failed program was: Possibly also fixed with that LDFLAGS trick. Mutt 1.3.22.1i did build fine for me with libiconv-1.7 on NetBSD.
Re: iconv etc
Lars Hecking wrote: configure:6558: checking for iconv configure:6576: gcc -o conftest -Wall -pedantic -g -O2 -I/home/will//include -I/home/will/include -L/home/will//lib -L/home/will/lib conftest.c 15 /tmp/cca149331.o: In function `main': /home/will/mutt-1.3.22.1/configure:6570: undefined reference to `libiconv_open' /home/will/mutt-1.3.22.1/configure:6571: undefined reference to `libiconv' /home/will/mutt-1.3.22.1/configure:6572: undefined reference to `libiconv_close' Ok. You probably need to run configure as $ LDFLAGS=-R/home/will/lib ./configure ... seems to work here. checking whether the C compiler (gcc -R/home/will/lib) works... yes checking whether the C compiler (gcc -R/home/will/lib) is a cross-compiler... no but the same errors checking whether this iconv is good enough... no configure: error: Try using libiconv instead [sepia]$ grep libiconv config.log |grep undefined /home/will/mutt-1.3.22.1/configure:6570: undefined reference to `libiconv_open' /home/will/mutt-1.3.22.1/configure:6571: undefined reference to `libiconv' /home/will/mutt-1.3.22.1/configure:6572: undefined reference to `libiconv_close' w -- Sintax error in config file! (line 378) aborted! PGP Public Key: http://infinitejazz.net/will/pgp/
Re: 1.3.x series need for iconv/libiconv
Sitting at the campfire, [EMAIL PROTECTED] told: I take your point about Solaris but it also required libiconv on a RedHat 6.1 system. Debian slink (2.1) also needs it. Kai -- x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x Kai Blin(mailto:[EMAIL PROTECTED]) Webmaster Inst. of Human Genetics Dept. of Molecular Genetics Wilhelmstr 27 phone (49)7071-2974890 D 72074 Tuebingen, Germany fax (49)7071-295233 http://www.uni-tuebingen.de/uni/thm/molgen/molgen.html Do molecular biologists wear designer genes? x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x PGP signature
Re: 1.3.x series need for iconv/libiconv
[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote : I have now built mutt 1.3.7 in four different places, two of the four required that I get libiconv as the existing iconv wasn't good enough. The two places that needed libiconv were Solaris 2.6 and Red Hat Linux release 6.1. I think this may cause problems when this gets to a general release version as one of mutt's major advantages is that it builds 'out of the box' on most Unix/Linux systems without requiring any 'bleeding edge' libraries. Hi, no, it;s not a problem about development computers, that's a problem of solaris. I was talking about iconv problem with Brendan Cully and we were making some tests and we decided, that ppl on solaris have to use libiconv. -- Keso Very bad. VERY BAD. Sorry about that...
Re: 1.3.x series need for iconv/libiconv
On Thu, Aug 17, 2000 at 10:13:37AM +0200, Martin [Keso] Keseg wrote: [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote : I have now built mutt 1.3.7 in four different places, two of the four required that I get libiconv as the existing iconv wasn't good enough. The two places that needed libiconv were Solaris 2.6 and Red Hat Linux release 6.1. I think this may cause problems when this gets to a general release version as one of mutt's major advantages is that it builds 'out of the box' on most Unix/Linux systems without requiring any 'bleeding edge' libraries. Hi, no, it;s not a problem about development computers, that's a problem of solaris. I was talking about iconv problem with Brendan Cully and we were making some tests and we decided, that ppl on solaris have to use libiconv. I take your point about Solaris but it also required libiconv on a RedHat 6.1 system. -- Chris Green ([EMAIL PROTECTED]) Home: [EMAIL PROTECTED] Work: [EMAIL PROTECTED] WWW: http://www.isbd.co.uk/
Re: 1.3.x series need for iconv/libiconv
On 2000.08.17, in [EMAIL PROTECTED], "Martin [Keso] Keseg" [EMAIL PROTECTED] wrote: The two places that needed libiconv were Solaris 2.6 and Red Hat Linux release 6.1. no, it;s not a problem about development computers, that's a problem of solaris. I was talking about iconv problem with Brendan Cully and we were making some tests and we decided, that ppl on solaris have to use libiconv. I've yet to see why more recent versions of Solaris than 2.6 would require libiconv. But 2.6 is three years old. I'd sooner recommend upgrading your OS, if you have that authority and aren't bound by poor applications or paranoid application developers. :) Solaris 7 and 8 seem fine with their native iconv interfaces. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
1.3.x series need for iconv/libiconv
I have now built mutt 1.3.7 in four different places, two of the four required that I get libiconv as the existing iconv wasn't good enough. The two places that needed libiconv were Solaris 2.6 and Red Hat Linux release 6.1. I think this may cause problems when this gets to a general release version as one of mutt's major advantages is that it builds 'out of the box' on most Unix/Linux systems without requiring any 'bleeding edge' libraries. -- Chris Green ([EMAIL PROTECTED]) Home: [EMAIL PROTECTED] Work: [EMAIL PROTECTED] WWW: http://www.isbd.co.uk/
