[tlbuild] interact.cc and getline insanity

Mojca Miklavec mojca.miklavec.lists at gmail.com
Thu Apr 24 10:05:13 CEST 2014


On Thu, Apr 24, 2014 at 2:13 AM, Karl Berry wrote:
>
> The actual failure is about "getline" not being declared.  It's unclear
> to me as to why.  From the error message, my only guess is that the
> types of the arguments in the getline() call in readpipeline() do not
> precisely match the ones in the system headers

See http://gcc.gnu.org/ml/gcc-help/2005-01/msg00251.html

>>>
The getline function is not portable.  It is GNU/Linux specific.  It
is documented as such on the manpage and in the libc manual.  The
function is not available in the Solaris libraries.  You will have to
provide your own version.
<<<

I can confirm that I'm unable to get a minimal example with
getline(char **, size_t *, FILE *) working and I don't know how
fdopen() can be translated into an ifstream (which would allow us to
use the getline from C++).

> Anyway, I don't know if anything can be done (short of your reinstating
> the kludge from last year, which created other problems on other
> systems, as I recall), but ... reporting ...

I don't know what fdopen is, but if there is no way to use C++ streams
to read that, I would suggest creating a configure test for checking
whether getline(char **, size_t *, FILE *) works. And then use
something like this to conditionally define getline when absent:


#ifndef HAVE_GETLINE

size_t getline(char **lineptr, size_t *n, FILE *stream) {
...
}

#endif

(One example is here:
http://stackoverflow.com/questions/735126/are-there-alternate-implementations-of-gnu-getline-interface,
but the code could just as well contain that "kludge" from last year.
But it would only be used on systems without getline support.)

Mojca

To Nelson: the problem is not in that private function.



More information about the tlbuild mailing list