brandonthestark
brandonthestark

Reputation: 21

Build Error in visual Studio in perlio.h and iobuf

I am trying to compile some project using visual studio 2015 RC but I am facing issues when it tries to compile perlio.c. From what I have read this error is related to Visual Studio 2015 rather than the application that I am trying to build. I have the following error:

C:\Program Files (x86)\Windows Kits\10\include\10.0.10056.0\ucrt\errno.h(112): note: see previous definition of 'ENOTSOCK'
perlio.c(2896): error C2039: '_file': is not a member of '_iobuf'
C:\Program Files (x86)\Windows Kits\10\include\10.0.10056.0\ucrt\corecrt_wstdio.h(26): note: see declaration of '_iobuf'

Command errors:
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.22816 for x86

So how to solve this error:

_file' is not a member of '_iobuf'

Upvotes: 2

Views: 3376

Answers (1)

Arnavion
Arnavion

Reputation: 3978

Just found this while hitting it myself. Presumably you were compiling the official CPAN Perl source. It has many problems while compiling with VS 2015 from its extensive use of the internals of the FILE struct. The new CRT that ships with 2015 (the Win 10 Universal CRT) has changed the FILE struct to an opaque one, as @Michael Burr mentioned in the comment.

typedef struct _iobuf
{
    void* _Placeholder;
} FILE;
  • perlio.c has multiple cases of trying to use FILE::_base and FILE::_ptr. These can be disabled by undefining USE_STDIO_BASE and USE_STDIO_PTR in config.h. (In a clean build config.h is generated by copying config_H.vc)

  • perlio.c also uses FILE::_file. This one is not controlled by any #define. The only way is to remove the offending line.

  • win32.c extensively uses internals of the FILE struct, such as in fdupopen where it tries to generate a new FILE* from an existing one for the same filename, open mode and file position. There is no POSIX way to do this, and I don't know if there's any WinAPI to do it either.

  • win32.c also tries to provide a wrapper around gets(), which has also been removed. (It was removed from the C and C++ standards for being insecure.)

For the last two points, I have not found any workaround either. For now, you have to either use an older VS to compile Perl, or use 2015 but with an older SDK.

Edit: You can follow the progress on this on Perl's bug tracker (ID:125714). For better or worse, their workaround seems to be to simply cast the pointer to the new internal struct and access that one's internals.

Upvotes: 4

Related Questions