Build.bat for MSVC 2015

[Antonio Linares]

Tim,

Please post here the contents of link.log

[TimStone]

The error is:
LINK : fatal error LNK1181: cannot open input file '%fwdir%\lib\FiveH64.lib'

In the .mak file:
echo %fwdir%\lib\FiveH64.lib %fwdir%\lib\FiveHC64.lib >> msvc.tmp

FiveH64.lib and FiveHC64.lib are in the C:\FWH64\lib folder

The path is:
FWDIR=c:\fwh64

[Antonio Linares]

Tim,

Please replace %fwdir% with %FWDIR%

[TimStone]

I already tried that. I tried again. It makes no difference.

I'm wondering if there is an issue with it not thinking this is a 64 bit app. It says it can't open the .lib file, not that it can't find it ( if that makes a difference ).

The files are from you and dated 3/30/16

I commented that one out and tried to see what happens. The next .lib gets the same error message. So it is not happy with the .lib files ?

[Antonio Linares]

Tim,

Do you have the libs here ?

FWDIR=c:\fwh64

%FWDIR%\lib ?

Please check that they are there

[TimStone]

The libs are all in the right place. I checked that before posting.

Everything builds, and the .obj files all link in, but then it replies that it cannot open the .lib files. If I comment some, then the first one it sees will generate the same message.

[Antonio Linares]

Tim,

Lets have another TeamViewer session

[TimStone]

I sent you an email with the Team Viewer info and the computer is setup for you.

I also have a Go32.bat and a 32 bit mak file in a separate folder. That calls the 32 bit libs and it fails at exactly the same place. I did other testing where I commented out all Harbour and FWH libs, and it does link all of the windows libs without a problem.

If I build these using the Visual Studio 2015 Community edition, the programs do completely assemble and run. However, I have not resolved a few performance issues with that so I can't use those for clients at this time. The main issue there is that I am apparently calling one incorrect library because clicking n a check box removes the associated text ( as it does with a radio button ). This was also a problem with VS 2013. Once I figure out that issue, those builds might be OK.

I imagine it is going to be something to do with the format of the .mak file.

I also copied both folders to my Surface Book, and it has the same exact error.

Tim

[TimStone]

The problem continues. I'm using the .bat and .mak files discussed previously. We've had errors formatting the .mak file which are all corrected.

This is using Harbour, FWH 16.03, and MSVC 2015. This is to be a 64 bit build, but the linker is acting like it's a 32 bit build and giving the following error on ALL 64 bit libs that are to be linked in:

C:\Program Files (x86)\Windows Kits\10\lib\10.0.10586.0\um\x64\vfw32.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'X86'

I apparently need to add a line to the .mak file that makes this application target machine x64. It's not handled in any of the samples we have seen posted.

Here is the Link command from the .mak file:

link @msvc.tmp /nologo /subsystem:windows /NODEFAULTLIB:msvcrt > link.log

Ideas ?

[Antonio Linares]

Tim,

VS vcvarsall.bat is not properly being called

VS vcvarsall.bat selects to work with 32 or 64 bits

[TimStone]

The call is right, the file is there ...

[Antonio Linares]

Tim,

This error means that it is building in 32 bits mode:

library machine type 'x64' conflicts with target machine type 'X86'

[TimStone]

Yes, that is what I have been trying to point out.

By deduction:

1) Harbour translates .prg to .c. That is not specific to 32 or 64 bit ...
2) The C compiler translates .c to .obj. I don't know if that is specific to 32 or 64 bit.
3) The linker obviously thinks this is 32 bit code.
4) The .lib files are ALL 64 bit ( harbour and FWH )

So ... do we have a flag for the c compiler and/or linker that push them to build 64 bit ?

Tim

[Antonio Linares]

Tim,

It is not a flag. When we call vcvarsall.bat with the right parameter, a different C compiler is selected.