Windows8 problem

[codemaker]

I recently tried to compile and link the application which I am developing for some time. I am working on Windows 7, using xHArbour December 2012/January 2013 and FWH 13.04
When I regularely install xHarbour and FWH on Windows8 machine I have this problem:
- The compiling went fine
- Linking produce this error:

Windows8 machine is 64-bit processor

Code: Select all  Expand view

Type: C >>>xlink.exe -NOEXPOBJ -MAP -FORCE:MULTIPLE -NOIMPLIB -subsystem:windows -UNMANGLE -LIBPATH:"c:\fwh1304\lib" -LIBPATH:"C:\xhbjan13\Lib" -LIBPATH:"" -LIBPATH:"C:\fwh1304\lib" -LIBPATH:"C:\xhbjan13\lib" -LIBPATH:"C:\xhbjan13\c_lib" -LIBPATH:"C:\xhbjan13\c_lib\win"  "obj32\badmin.obj" "obj32\prv2pdf.obj" "obj32\licmanag.obj" "obj32\marx.obj" "obj32\qftp.obj" "obj32\shiftdif.obj" "obj32\tcbackup.obj" "obj32\mailer.obj" "obj32\chkmail.obj" "obj32\see32fun.obj" "obj32\xviewer.obj" "obj32\b_compan.obj" "obj32\b_worker.obj" "obj32\b_chkfls.obj" "obj32\initdbf.obj" "obj32\b_dept.obj" "obj32\msgcalc.obj" "obj32\mycalend.obj" "obj32\paypolic.obj" "obj32\rndpolic.obj" "obj32\holidays.obj" "obj32\holipack.obj" "obj32\payrep02.obj" "obj32\missingp.obj" "obj32\borisrep.obj" "obj32\sumh.obj" "obj32\tajm.obj" "obj32\brat.obj" "obj32\onduty.obj" "obj32\barcodes.obj" "obj32\purgeh.obj" "obj32\histedt.obj" "obj32\imports.obj" "obj32\jobs.obj" "obj32\shifts.obj" "obj32\schedule.obj" "obj32\daysoff.obj" "obj32\indexes.obj" "obj32\fancy.obj" "obj32\newcomp.obj" "obj32\prtotals.obj" "obj32\borisfnc.obj" "obj32\punchman.obj" "obj32\payrep01.obj" "obj32\first1.obj" "obj32\getdbf.obj" "obj32\punchm.obj" "obj32\alert.obj" "obj32\longnam2.obj" "obj32\commonfn.obj" "obj32\browse.obj" "obj32\wininet.obj" "obj32\badmin.res" "mem32.lib" "send32.lib" "oledlg.lib" "xhbzip.lib" "xhbzipdll.lib" "c:\fwh1304\lib\FiveHCM.lib" "c:\fwh1304\lib\FiveHMX.lib" "C:\xhbjan13\Lib\OptG.lib" "C:\xhbjan13\Lib\xhb.lib" "C:\xhbjan13\Lib\dbf.lib" "C:\xhbjan13\Lib\nsx.lib" "C:\xhbjan13\Lib\ntx.lib" "C:\xhbjan13\Lib\cdx.lib" "C:\xhbjan13\Lib\rmdbfcdx.lib" "C:\xhbjan13\Lib\ct3comm.lib" crt.lib kernel32.lib user32.lib winspool.lib ole32.lib oleaut32.lib odbc32.lib odbccp32.lib uuid.lib wsock32.lib ws2_32.lib wininet.lib advapi32.lib shlwapi.lib msimg32.lib mpr.lib OleDlg.lib version.lib comctl32.lib comdlg32.lib gdi32.lib shell32.lib winmm.lib lz32.lib Netapi32.lib -out:"c:\clock\admin.exe"<<<

xLINK: fatal error: No argument specified with option /LIBPATH.

Type: C >>>Couldn't build: admin.exe<<<
Type: C >>>TMAKEPROJECT<<<
Type: C >>>TMAKEPROJECT:REFRESH<<<
Type: N >>>      1405<<<

I am not using this variable/path/constant (whatever it is) at all anywhere...

Using XBP file as I do on Windows7

Maybe it is related somehow but after I installed FWH and xHarbour on Windows8 and also create dthe folder for developing the application, I cannot just doubleclick in application folder on a XBP file and load xBuildW with a XBP file. It just tries to compile without a dialog and trows the above error.
When I run xBuildW from xHArbour folder and load the XBP file from developing folder - again the same error while linking.

Cannot find
- The error cause
- The reason why cannot doublme click and load XBP in xBuildW as I do in Windows7

[Antonio Linares]

Boris,

xlink is reporting you this error:
xLINK: fatal error: No argument specified with option /LIBPATH

And you are using an empty libpath here:
-LIBPATH:""

please remove it and try it again

[codemaker]

Antonio, I am using a graphical interface to compile and link my projects.
I cannot find any reference to libpath anywhere.

I have a lot of projects on Windows7 and all of them uses the same xHB and FWH structures.
I did the same (actually copy XBP file from one of my Windows7 projects) on Windows8 machine but cannot link.
I compared XBP between Windows7 and Windows8 XBP files (graphical setup and textual setup) and afre identical except of course the needed files.

I am totally confused, it looks like some folder is not found but the folder structures are identical, xHB and FWH are identically installed, XBP are identically configured

The only difference is that on Windows8 I cannot just double click on XBP and the graphical interface for compiling and link loads as on Windows7. I have to move to xHB\bin and run xBuildW and load the XBP from develop folder... Maybe this is something to take care about?

[Antonio Linares]

Boris,

I don't use xhb.com so I can't be of much help about it.

I simply revised what you posted:

Type: C >>>xlink.exe -NOEXPOBJ -MAP -FORCE:MULTIPLE -NOIMPLIB -subsystem:windows -UNMANGLE -LIBPATH:"c:\fwh1304\lib" -LIBPATH:"C:\xhbjan13\Lib" -LIBPATH:"" -LIBPATH:"C:\fwh1304\lib" -LIBPATH:"C:\xhbjan13\lib" -LIBPATH:"C:\xhbjan13\c_lib" -LIBPATH:"C:\xhbjan13\c_lib\win"

libpath is there, so from the builder that you use there must be a place where libpath can be set.

[carlos vargas]

xbuild add the LIBPATH:"", not the users. atric lease

[Horizon]

Hi Boris,

This is not a Win 8 problem. it also occurs in win 7.

This problem is related to xHb builder. (I think there was a change about arrays. I can not remember clearly).

Solution : Open the projects in xhb builder. Click 4. Click fivewin. click lib folder get and save project. then try to build now. it should work.

[codemaker]

Thanks, will try this

[Roger Seiler]

To get the 8/13 version of xHb.com working correctly, the following workarounds are needed...

1. Include these three LIBs into your XBP:

https://code.google.com/p/harbour-and-x ... me=png.lib


http://code.google.com/p/harbour-and-xh ... b&can=2&q=


http://code.google.com/p/harbour-and-xh ... b&can=2&q=

2. Also, you must put this line in your app's main prg...

FUNCTION FWOpenPngFile() ; RETURN 0

If you do the above 2 steps, then you shouldn't get the /LIBPATH error with xBuildW 8/13.


There is a quirk now with xBuildW where it won't display the app's root path on the
top tab of xBuildW the first time in a work session that you open the xbp file. Just open the
xbp file a second time and then it will accept the root path info so you won't have to type it
in manually. Any other xbp files subsequently opened in the same xBuildW worksession will
also accept the root path correctly.

I saw a question earlier about why one would use xHb.com instead of the current Harbour.
Though I've read good things about the current Harbour, it still seems terribly cumbersome
to set up. If you Google it, you aren't even directed to the current build -- instead a 2007
build in SourceFuge. There is a document available somewhere here describing a complicated
process for getting setup with Harbour. The complexity of the process makes me wonder how
many subtle problems I'd have to deal with trying to do it. A big advantage of xBuildW is
the ease of installing it and setting up a make. By contrast, installing Harbour and setting
up a make for an app using Harbour doesn't look easy or intuitive.

However, xBuildW seems to be getting a bit buggy (as suggested by the workarounds above), so
maybe I'll have to go the Harbour route eventually. However, because of the apparent
complexity, I expect that I'd have to set aside at least a week to get Harbour up and
running and work out the hidden subtle issues that are bound to be there, because setting it
up doesn't seem to be a clean process.

[codemaker]

Unfortunately this will not solve the problem.

It has to do something with xBuildW where it looks for various necessary lib files.
Don't know how to solve this

[Antonio Linares]

Boris,

I know this is not an inmediate solution, but in medium-long term you will he very happy for the shift, if you use Harbour and a make file.

Or it may be easier for you to use the free xHarbour and a makefile as an intermediate step. This way you will have 100% control over the building process of your apps.

[Roger Seiler]

Codemaker,

Did you put the three LIB files mentioned above into c:\xhb\lib and then on tab #3 of xBuildW add them to your list of libs to be used by your app?

That works for me - also with the dummy function call to my main prg which is also mentioned above.

Good luck,

- Roger

[Roger Seiler]

...dummy function call IN my main prg...

[codemaker]

Yes Roger I did that. Same problem.

Finally I created the shortcut on desktop and I was able to compile using graphical xBuildW.EXE

[Antonio Linares]

Boris,

FWH provides a vmh.prg in samples folder that is a GUI for Harbour's own make (hbmk2.exe) and provides the same functionality as xBuildW.EXE

And you can review, modify, inspect, etc. everything in vmh.prg

[codemaker]

Yes Antonio,
you pointed me to this PRG when I had problems at the very beginning with FWH1304
I compiled VMH.PRG and the resulting EXE seems to work good.

Will keep an eye on this utility
Thanks