usr1 posted some time ago that he experienced a problem with creating a library, and combining it with a main program. The relevant part from the long thread here I think is this:
==================
You could put the subroutines in a library thus
wfl386 /c sub1.for
wfl386 /c sub2.for
wlib mylib.lib +sub1.obj +sub2.obj
Then compile and link mainp.for to the library
wfl386 mainp.for mylib.lib
==================
(BTW, what's the /c for?
I wrote a small fortran program that contained about 10 lines of code and another for a subroutine. Using the IDE, I successfully executed the program. There was no obvious way there to create a lib for the subroutine, so I tried the method above. All went well until I executed the wlf386 command. I got the E3033 error message and a complaint about "Error: ... line 4:directive error near librarymylib.lib". That was followed by "Error: linker returned a bad status"
I found a description for 3033, MSG 2033,3033 directive error near ’%s. Whatever %s means?
Later others thought it might be a bug. Someone suggested using wfc386/wlink as a workaround, and that ended the thread.
So what is the right answer? wfc386/link mainp.for mylib.lib
CL is C-compile and Link, FL is Fortran-compile and Link
WCL is Watcom C-compile and Link, WFL is Watcom Fortran-compile and Link
WCL386 is Watcom C-compile and Link (32 bit for 386 and above)
and, finally,
WFL386 is Watcom Fortran-compile and Link (32 bit for 386 and above)
If you just want to compile you either use the /c (compile only) option OR
use a different tool (such as WFC386 (Watcom Fortran-Compile (32 bit)))
> You could put the subroutines in a library thus
> wfl386 /c sub1.for
> wfl386 /c sub2.for
> wlib mylib.lib +sub1.obj +sub2.obj
> Then compile and link mainp.for to the library
> wfl386 mainp.for mylib.lib
> ==================
> (BTW, what's the /c for?
Do you _never_ read the help files? Or, execute
wfl386 |more
...
> and another for a subroutine. Using the IDE, I successfully executed the
> program. There was no obvious way there to create a lib for the
> subroutine,...
I've told you how to do this several times before, as well, and it's also in the tutorial you didn't like.
Create a new project for the library you want to make. The IDE will prompt for the image type to build; select "Lib". Then you reference that library in whatever project(s) need it just like the libraries are referenced in the "kitchen" tutorial.
It's the same principle as used in Visual Studio w/ only a very slightly different interface.
> ... so I tried the method above. All went well until I executed
> the wlf386 command. I got the E3033 error message and a complaint about
> "Error: ... line 4:directive error near librarymylib.lib". That was
> followed by "Error: linker returned a bad status"
...
> Later others thought it might be a bug. Someone suggested using
> wfc386/wlink as a workaround, and that ended the thread.
> So what is the right answer? wfc386/link mainp.for mylib.lib
...
It is a bug. Did a test here. Built a test app and library testfor.for, testlib.lib
The directive file generated was
system nt
name testfor
file testfor.obj
librarytestlib.lib
Note there's a missing space on the library directive--it should be
library testlib.lib
The same under Watcom V11 works correctly so this somehow got introduced into the current (or an earlier and is still here) OW build. :(
wfc386 and wlink will work.
For the above
wfc386 testfor.for
wfc385 testlib.lib
wlib testlib +testlib.obj
wlink system nt name testfor file testfor[.obj] library testfor[.lib]
Normally one makes a make file or uses a batch file rather than all manually, of course.
> WFL386 is Watcom Fortran-compile and Link (32 bit for 386 and above)
...
Kevin, note that the E3033 is a real problem in wfl386 in OW 1.9, though.
The .lnk file generated by wfl386 now is missing a space on the library directive line between the directive and the file name. This causes the link step to fail.
It is a bug introduced somewhere along the way in OW builds--I had continued to use Watcom V11.6 until trying to see if could lead our friend here out of the wilderness I did download V1.9 of OW. I have just confirmed (see other longer post) that it does the same thing here.
Can't see how that got past any regression testing into a release build...
> Then compile and link mainp.for to the library
> wfl386 mainp.for mylib.lib
...
> the wlf386 command. I got the E3033 error message and a complaint about
> "Error: ... line 4:directive error near librarymylib.lib"....
BTW, the clue as to what went wrong is pretty easy to spot--the "directive error near librarymylib.lib" has the library directive and your requested library run together as noted before.
You can see this if you use the -FD switch to save the created .lnk directive file (that otherwise is automagically deleted) and then look at it as I did in the other posting.
If there isn't anything about a patch at the OW site or somebody around to make a corrected rebuild in the short term, if you'll provide a valid addy I'll be glad to forward the wfl386 executable from the V11 build that works. I don't know for certain it will work w/ the OW distribution -- well, let's see...ren, copy, wfl386...voila!!
Putting that version of wfl386.exe in the OWATCOM\BINNT directory allowed to use it to build an executable compiled from a main .for and linking w/ a .lib file w/o the E3033 error. Since Watcom is defunct and passed on to OW, I don't see any problem in allowing the executable to be used to get around a problem caused by some update build in the OW distribution.
On 11/4/2011 4:12 PM, Hans-Bernhard Bröker wrote:
...
> The bug was fixed in the development version, and the fix announced
> right there in the thread days before it petered out.
Interesting...I had totally forgotten that from a year+ ago even though I read and responded in the thread... :(
But, the Winders build server is down so is there anywhere if the corrected build wasn't inserted into the 1.9 distribution to actually get a correct build at the moment? Don't know the OW site intimately, but a moderately quick perusal didn't help...
> On 11/4/2011 4:12 PM, Hans-Bernhard Bröker wrote:
> ...
>> The bug was fixed in the development version, and the fix announced
>> right there in the thread days before it petered out.
> Interesting...I had totally forgotten that from a year+ ago even though
> I read and responded in the thread... :(
> But, the Winders build server is down so is there anywhere if the
> corrected build wasn't inserted into the 1.9 distribution to actually
> get a correct build at the moment? Don't know the OW site intimately,
> but a moderately quick perusal didn't help...
> --
Grab it from the linux build server, as long as it is still up.
Actually, you can hexedit the appropriate string in the version 1.9 wfl386.exe file, if you are brave enough. Shorten library to lib followed by 4 trailing spaces. Don't wish to talk OP through that process, however.
>Actually, you can hexedit the appropriate string in the version 1.9 >wfl386.exe file, if you are brave enough.
Just make a backup copy first.
I did too much of that for the Ph.D. thesis, WP 4.2 for DOS, getting the font changes for Greek
into the auto-generated index and TOC. Fortunately, there were not too many Greek letters in index entries. But I was too F***ing stubborn to change my wordings to avoid the issue.
Still, it was less fuss than TECO and a homebrew runoff for RT-11 on 8" floppies that I used
to write the Master's. (Run through the daisy-wheel, change to the Greek wheel and run it
through again. Joy.) I still have those floppies around, somewhere ...
> CL is C-compile and Link, FL is Fortran-compile and Link
> WCL is Watcom C-compile and Link, WFL is Watcom Fortran-compile and Link
> WCL386 is Watcom C-compile and Link (32 bit for 386 and above)
> and, finally,
> WFL386 is Watcom Fortran-compile and Link (32 bit for 386 and above)
> If you just want to compile you either use the /c (compile only) option OR
> use a different tool (such as WFC386 (Watcom Fortran-Compile (32 bit)))
Oh, I only want to use Fortran, but was attracted to the sequence, since I was trying to build a library to use with a main program.
>> Actually, you can hexedit the appropriate string in the version 1.9
>> wfl386.exe file, if you are brave enough.
> Just make a backup copy first.
> I did too much of that for the Ph.D. thesis, WP 4.2 for DOS, getting the font changes for Greek
> into the auto-generated index and TOC. Fortunately, there were not too many Greek letters
> in index entries. But I was too F***ing stubborn to change my wordings to avoid the issue.
> Still, it was less fuss than TECO and a homebrew runoff for RT-11 on 8" floppies that I used
> to write the Master's. (Run through the daisy-wheel, change to the Greek wheel and run it
> through again. Joy.) I still have those floppies around, somewhere ...
As a newcomer to this, it looks like if anyone wants to build a library per the above commands they can't. Is there another way?
>> Actually, you can hexedit the appropriate string in the version 1.9
>> wfl386.exe file, if you are brave enough.
> Just make a backup copy first.
> I did too much of that for the Ph.D. thesis, WP 4.2 for DOS, getting the font changes for Greek
> into the auto-generated index and TOC. Fortunately, there were not too many Greek letters
> in index entries. But I was too F***ing stubborn to change my wordings to avoid the issue.
> Still, it was less fuss than TECO and a homebrew runoff for RT-11 on 8" floppies that I used
> to write the Master's. (Run through the daisy-wheel, change to the Greek wheel and run it
> through again. Joy.) I still have those floppies around, somewhere ...
As a newcomer to this, it looks like if anyone wants to build a library per the above commands they can't. Is there another way?
> Grab it from the linux build server, as long as it is still up.
OH...DOH!
I was presuming those were running Linux builds under Linux; but I realize that's not the way builds are built when you say so... :(
> Actually, you can hexedit the appropriate string in the version 1.9
> wfl386.exe file, if you are brave enough. Shorten library to lib
> followed by 4 trailing spaces. Don't wish to talk OP through that
> process, however.
Yeah, that would work but would seem far above OP's skill set, indeed.
> As a newcomer to this, it looks like if anyone wants to build a library
> per the above commands they can't. Is there another way?
Well, yes, I already posted an example using wfc386 and wlink to do the same thing as wfl386 does. All wfl386 is is a front end for them; it's nothing magic, just a convenience.
> On 11/4/2011 8:40 AM, Kevin G. Rhoads wrote:
>> ...
>>> wfl386 /c sub1.for
>> ...
>>> (BTW, what's the /c for?
>> CL is C-compile and Link, FL is Fortran-compile and Link
>> WCL is Watcom C-compile and Link, WFL is Watcom Fortran-compile and Link
>> WCL386 is Watcom C-compile and Link (32 bit for 386 and above)
>> and, finally,
>> WFL386 is Watcom Fortran-compile and Link (32 bit for 386 and above)
>> If you just want to compile you either use the /c (compile only)
>> option OR
>> use a different tool (such as WFC386 (Watcom Fortran-Compile (32 bit)))
> Oh, I only want to use Fortran, but was attracted to the sequence, since
> I was trying to build a library to use with a main program.
We build several libraries in our software using 1.9
of Open Watcom and do not have this problem. However,
we use all command line tools. Works a lot better
with 700,000 lines of F77 code, 10,000 lines of C code
and 10,000 lines of C++ code. And over 6,000
subroutines and functions.
And we use the free crimson editor for source code
editing.
> We build several libraries in our software using 1.9
> of Open Watcom and do not have this problem. However,
> we use all command line tools....
It only exists in wfl386 (which is also command-line tool) just the integrated compile/link front end that calls wfc386 and wlink in turn (I'm not sure whether can also cram in wlib calls or not; don't really think so, but never investigated fully), Lynn. You'll never see it otherwise using the individual compile/librarian/link utilities.
The IDE builds a make file and submits it to wmake so it doesn't see the problem, either.
And, of course, the OP has been pointed to the workaround or I offered the V11 version and also provided the _direct_ link to the build server from which he can download the last build in which the problem has been fixed.
Is that sufficient? Would seem to most to be so, but apparently not to this OP; he seems to prefer to complain and not bother with taking any advice or direction nor bother to actually _read_ documentation it would appear.
> And we use the free crimson editor for source code
> editing.
I wasn't aware of Crimson...just went and found it. Interesting.
I've used Brief since first PC compiler and have so many customized macros I have never yet been able to find a satisfactory replacement. Fortunately, having retired from active consulting, I no longer code "in anger" so it really isn't terribly important any longer.
For any who also miss Brief key layouts, I've recently discovered a Windows pseudo-replacement at <www.briefeditor.com> It has key mappings and the in-editor compilation/error, etc., the one lack in my case is it doesn't implement Brief macros so all my customization is lost. In private conversation w/ the author, he says it's on the horizon, but it appears to me very unlikely it will ever happen both because it's a sizable effort and the present command syntax isn't drop-in Brief compatible as if it were intended from the beginning to do such. But, it limited testing it seems stable and functional.
>> We build several libraries in our software using 1.9
>> of Open Watcom and do not have this problem. However,
>> we use all command line tools....
> It only exists in wfl386 (which is also command-line tool) just the
> integrated compile/link front end that calls wfc386 and wlink in turn
> (I'm not sure whether can also cram in wlib calls or not; don't really
> think so, but never investigated fully), Lynn. You'll never see it
> otherwise using the individual compile/librarian/link utilities.
> The IDE builds a make file and submits it to wmake so it doesn't see the
> problem, either.
> And, of course, the OP has been pointed to the workaround or I offered
> the V11 version and also provided the _direct_ link to the build server
> from which he can download the last build in which the problem has been
> fixed.
> Is that sufficient? Would seem to most to be so, but apparently not to
> this OP; he seems to prefer to complain and not bother with taking any
> advice or direction nor bother to actually _read_ documentation it would
> appear.
Dont know. I'm an old mainframe hacker who moved to
PrimeOS to Vax to Unix to PC. Except for the PC, I
always used command lines tools instead of IDEs.
Nowadays I prefer IDEs but they must work and work
well. Watcom's IDE does not meet this requirement,
it is just too simplistic. So we just use the command
line tools provided by Watcom as they are robust and
simple.
We use Visual Studio exclusively for our user interface
(600,000 lines of C++ code) and some days I want to
throw it out the nearest window. BTW, when I first
tried to port our F77 code to Intel Fortran, we
overloaded it's linker internal tables and had to wait
a couple of months for a patch. Then I ran into their
zero init bug and gave up in disgust.
> Dont know. I'm an old mainframe hacker who moved to
> PrimeOS to Vax to Unix to PC. Except for the PC, I
> always used command lines tools instead of IDEs.
> Nowadays I prefer IDEs but they must work and work
> well. Watcom's IDE does not meet this requirement,
> it is just too simplistic. So we just use the command
> line tools provided by Watcom as they are robust and
> simple.
> We use Visual Studio exclusively for our user interface
> (600,000 lines of C++ code) and some days I want to
> throw it out the nearest window. BTW, when I first
> tried to port our F77 code to Intel Fortran, we
> overloaded it's linker internal tables and had to wait
> a couple of months for a patch. Then I ran into their
> zero init bug and gave up in disgust.
...
Pretty similar path from Philco-->CDC Cyber/Star-->DEC 10 -->VAX and PDP's of various ilks --> period of embedded systems far removed from any Fortran at all -->back to VAX -->PC OS/2 to --> NT4 (first MS OS used "in anger")
The code base that got me to the Watcom compiler was moved from VAX to OS/2 (Watcom) then to the DVF to move it to NT4. It doesn't have a user interface other than terminal; I wrote a small demo and a proposal to build one w/ Tcl/Tk but the client never funded the development.
I didn't do the OS/2 conversion from VAX but picked up a modification and support and the move to NT4 (when also moved it from OW as the client wanted a commercially supported compiler. (Of course, that DVF morphed to CVF then shortly died is an ironic sidebar.) It's not as large as yours (and I've never counted lines nor routines) but is a suite of half-dozen multiple independent executables using shared memory and semaphores to monitor plant performance on real time basis using interface to plant control system and thermodynamics plant models for heat rate, etc., as well as interactive analysis tools and a historian, etc., etc., etc. No IDE here, either, I built onto the existing make files and use the JPSoft command interpreters on MS (or used REXX on OS/2) to build more sophisticated batch files for the compilation process and the configuration management package for source control and edit check-in/-out.
I've used the Visual Studio distributed with the DVF/CVF distribution some for small projects or playing around but don't believe I would ever willingly go that route on anything large; I can't stand the editor limitations/idiosyncracies (vis a vis the different idiosynracies that I _am_ used to :) ).
We've had at the Intel zero-init thing re: your code and the other extensions used that aren't supported by other potential choices otherwise ad nauseum in the past; I retired from active consulting not too long after the time Intel bought the compiler group from Compaq and the aforementioned project wasn't funded to provide any revenue so I've never updated either Fortran/C compilers nor Matlab license since ...and at this point don't expect to.
Kevin G. Rhoads wrote:
>> Actually, you can hexedit the appropriate string in the version 1.9
>> wfl386.exe file, if you are brave enough.
> Just make a backup copy first.
> I did too much of that for the Ph.D. thesis, WP 4.2 for DOS, getting the font changes for Greek
> into the auto-generated index and TOC. Fortunately, there were not too many Greek letters
> in index entries. But I was too F***ing stubborn to change my wordings to avoid the issue.
> Still, it was less fuss than TECO and a homebrew runoff for RT-11 on 8" floppies that I used
> to write the Master's. (Run through the daisy-wheel, change to the Greek wheel and run it
> through again. Joy.) I still have those floppies around, somewhere ...
Funny you mention TECO and RT-11. When I was in grad school, we had a MINC-11 lab computer, with 8" floppies and all sorts of a/d and d/a converters, digital i/o lines etc. I programmed it with RT-11 Fortran, and a bunch of "call ipoke" and "call ipeek" to control and read data from the instrumental contraption that I was hitched up to. TECO probably, but I think there was also a keypad editor called KED.
Lynn McGuire <l...@winsim.com> wrote:
> Dont know. I'm an old mainframe hacker
* Bullshit Alert!!! *
Nobody who works on mainframes calls himself a hacker
> who moved to PrimeOS to Vax to Unix to PC.
That puts it in context. Not only didn't you belong in the mainframe world
but you exhibited bad judgement! ;-) Even MVS 3.8J is better than the best
UNIX or PC OS.
> We use Visual Studio exclusively for our user interface
> (600,000 lines of C++ code)
Is that 600K lines of GUI? Things are worse than I imagined.
> We've had at the Intel zero-init thing re: your code and the other extensions used that aren't supported by other potential choices
> otherwise ad nauseum in the past; I retired from active consulting not too long after the time Intel bought the compiler group from
> Compaq and the aforementioned project wasn't funded to provide any revenue so I've never updated either Fortran/C compilers nor
> Matlab license since ...and at this point don't expect to.
The zero init port to non zero init has been just about
completed. The developer reported success right before
I threw some nasty bug reports at him. We may actually
get that project completed in the first quarter of 2012.
Then on to C++ !
