> That's probably a bug in libiconv - POSIX says that EILSEQ and ENOENT > must be distinct. [...] > > In terms of the build error on Lynx178, what I ended up doing > > was compile with -DEILSEQ=ENOENT. > > This smells wrong, but at least it worked for you, while we figure out > how to fix things properly.
I didn't know that the two values were required to be distinct. For Lynx178, it's easy to pick an arbitrary value that will not collide with any of the currently defined value, so I will do that. Thanks! > Still, it might be possible to figure out how to make > gnulib guarantee a distinct value even when linked with libiconv. I am not sure I understand what you mean. My suggestion was to have libiconv and gnulib use the same value for EILSEQ. As for gnulib, it uses an arbitrary value that's fairly large, compared to typical values, so it should be distinct in practice. I don't think libiconv imports any of the gnulib code, and in my experience, the first import of gnulib is a real pain because of the learning curve, particularly if the importer does not use automake. But once past this initial hurdle, I think the general impression in the GDB project is that we're not regreting the move. I think I've written some notes somewhere about how to do it, if anyone is interested. Cheers :) -- Joel
