-1

And should I have the same setting in all config.h files in the project?

Symptom: nmake attempting to build parts of the project at the MSVC 'Command Prompt' is throwing inconsistent dll linkage vsnprintf. Googling for that message says it's usually to do with macros not working consistently. I'm building a package that presumably works; I haven't changed the distro.

Those two Microsoft routines documented here. There's flags in the config.h files

/* Define to 1 if you have the `vsnprintf' function. */
/* #undef HAVE_VSNPRINTF */
...
/* Define to 1 if you have the `_vsnprintf' function. */
#define HAVE__VSNPRINTF 1

Some but not all config.h files are generated from config.h.in/configure.ac at package install. I seem to have different settings for HAVE_VSNPRINTF in different config.hs in different subtrees of the project. I don't want to override the distro, but that doesn't seem right(?)

vsnprintf is in MSVCRnnn.DLL where nnn is the MSVC release; I've installed v12.0/Update 5 Community. Why such an old version? ...

Background

I'm trying to build an ancient version of the Haskell Hugs compiler, September 2006. This is mostly written for Unix environments in C/C++. But I'm building on Windows 8.1, x64-based processor. The instructions I'm following are here; and that repo holds the whole directory structure I'm building (thank you Franklin Chen).

The Unix-oriented part I have built, using MinGW/MSYS, not Cygwin. (64-bit MinGW did not go well, so I reverted and used 32-bit.)

Now I'm trying to build the Windows part, which is essentially a GUI veneer over the Unix -- starting at 'Using Microsoft Visual C++' in the instructions. Visual Studio was not at all happy: the project files are .vcproj, no longer supported. I tried devenv /Upgrade to get them as .vcxproj. But then further problems trying MSBuild that it couldn't validate against an .xsd; either Microsoft.Build.{Core|Common}.xsd gave many rejections about missing types. So I've abandoned that approach.

So I'm at the instructions 'Driving Microsoft Visual C++ from the Command Line', using the MSVC-supplied .bat file to fire up the command line, as doco'd here. nmake is running but throwing heaps of inconsistent dll warnings, for vsnprintf only. I'm also getting differs in parameter lists for various routines; is that a knock-on error? Eventually nmake crashes out, without building the .exes I want.

AntC
  • 2,623
  • 1
  • 13
  • 20
  • I would strongly recommend using MSYS2 rather than MSYS , it is better all round. You can install 32bit or 64-bit build and targets. – M.M Apr 09 '20 at 08:01
  • I first tried MSYS2; the build routines kept barfing because MSYS2 defined environment variables Hugs hadn't heard of in 2006. (That's why I reverted to 32-bit.) My machine's Unix environment is only for building this app. – AntC Apr 09 '20 at 08:44
  • MSYS2 comes in 32-bit and 64-bit versions. There's no "revert to 32-bit" if you are using MSYS2 32-bit. – M.M Apr 09 '20 at 09:17

3 Answers3

1

The idea of the configure scripts is to figure out whether your compiler has vsnprintf. Of course various generated config.h files get different results, that is the entire point. If they all had vsprintf, there would be no need to check!

Having said that, I'd describe the configure.ac mechanism as positively ancient. On more than one occasion, I've found it easier to just create a new .vcxproj from scratch.

I'm not sure about the MSDN documentation you're linking. You link to the VC14.x documentation, which notes that vsnprintf has changed since VC12.0, which you claim to use.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • Thanks but sorry I don't understand: my compiler or my machine? If `vsnprintf` is on the _machine_ shouldn't all compilers use it? Especially if they're building the one app. I assumed `config.h` is to cope with compiling on different machines. Anyway: the `make` that works has `HAVE_VSNPRINTF 1`; the `nmake` that doesn't work has `HAVE_VSNPRINTF` not defined. – AntC Apr 09 '20 at 08:48
  • I linked the 2019 docos because that's all that's available on Microsoft's site. Thanks for the tip re the version change, just as well I installed VC12.0. – AntC Apr 09 '20 at 08:53
  • 1
    @AntC: `vsnprintf` is part of the Universal CRT and it's on every Windows 10 machines, but you specifically mention using Windows 8.1. The "compiling on every machine" logic is typical for Unix, but on Windows it's unheard of. The vast majority of Windows PC's do not even have a compiler installed. That's why you have Visual C++ redistributable libraries, and that installer also takes care of the Universal CRT on Win8.1 – MSalters Apr 09 '20 at 08:56
  • BTW the `.vcproj` comes with the distro (dated 2005), `configure.ac` has not touched it. – AntC Apr 09 '20 at 09:06
  • 1
    @AntC the compiler you are using to compile the project. As of right now, I have 3 different versions of MSVC and it's libraries on the same machine, because the projects I work on don't upgrade tools at the same time – Caleth Apr 09 '20 at 09:39
0

I've fixed this for this particular application. #define HAVE_VSNPRINTF 1, also #define HAVE_SNPRINTF 1 in config.h makes the inconsistent dll linkage vsnprintf error go away. That is, I changed those flags to same as in the configure.ac-generated config.h.

Within the project there's many config.h in different subtrees setting those flags. But there's only one file that reads it/takes action on it: src/machdep.c "Machine dependent code". That's #included by all applications. This application being essentially written for a Unix platform, I'd expect machine-wide settings.

I take the point in @MSalters' answer that a MSVC platform does not necessarily expect the same settings machine-wide. But this application has the Unix/MSys and MSVC environments tightly bound, so I'd expect they want consistency.

Then I'm making progress. I haven't got the whole application to compile yet: it's got further, so I have more inconsistent dll linkage ... errors for other routines. I can see further inconsistencies in flag settings in the config.hs.

AntC
  • 2,623
  • 1
  • 13
  • 20
0

Alternative answer:

The symptom C4273: 'xxx' inconsistent dll linkage is a Warning not an Error, so the compiler carries on. vsnprintf and friends format a list of arguments to an output buffer. So it probably doesn't matter if different .exes in the project link to different versions. At worst they'll produce different results in the output for the same arguments.

So just ignore the message, and don't worry about discrepancies in the config.h.

Full disclosure: after editting the config.h to make the vsnprintf etc messages go away; I have some residual inconsistencies re malloc and free -- despite editing the config.h for any settings to do with ALLOC. Differences in alloc behaviour between different .exes are more alarming.

AntC
  • 2,623
  • 1
  • 13
  • 20