Problem with a batch build script

I admit, it's been a while since I've last written batch build scripts
.... and it shows.
However, I cannot, for the life of me, understand what this error is
supposed to mean, nor what could be wrong with the script or the
link-er.

@echo off
cls

set F90C=ifort
set F90FLAGS=/nologo /libs:qwin /c
set LLIBS=/MACHINE:x86 /SUBSYSTEM:WINDOWS /NODEFAULTLIB:"libcmtd"
set SLINK=link

if "%1"==" " goto MISSING
%F90C% %1 %2 %3 %4 %5 %6 %7 %8 %9 %F90FLAGS%
%SLINK% %1 %2 %3 %4 %5 %6 %7 %8 %9 %LLIBS% /exe:%~n1.exe
echo %1.exe created!
goto END

:MISSING
echo Missing a filename maybe?
goto END

:END
@echo on

The error, upon invoking the script

qwin first.f90 second.f90

is

fatal error LNK1107: invalid or corrupt file: cannot read at 0x46

Does anyone know what could be wrong with it, or has encountered
anything like that before?

Environment: Windows XP/ifort



-- Luka

On 1/13/2012 7:49 PM, Luka Djigas wrote:
> I admit, it's been a while since I've last written batch build scripts
> ... and it shows.

<snip DOS batch>

I can't help you with this, as I gave up writing DOS batch scripts
long time ago.

My advice is to throw DOS batch scripts away. You have much better options
these days:

1. get cygwin for windows (free), and write all your scripts in a real scripting
language (bash)

2. get oracle VM box (free), install Linux, mount your windows disk
from Linux, and and write all your scripts in a real scripting
language (bash) (this is what I do now).

If you work somewhere where they still use DOS for scripts, you
can educate them to change to Bash.

--Nasser

On 1/13/2012 7:49 PM, Luka Djigas wrote:
> I admit, it's been a while since I've last written batch build scripts
> ... and it shows.
> However, I cannot, for the life of me, understand what this error is
> supposed to mean, nor what could be wrong with the script or the
> link-er.
>
> @echo off
> cls
>
> set F90C=ifort
> set F90FLAGS=/nologo /libs:qwin /c
> set LLIBS=/MACHINE:x86 /SUBSYSTEM:WINDOWS /NODEFAULTLIB:"libcmtd"
> set SLINK=link
>
> if "%1"==" " goto MISSING
> %F90C% %1 %2 %3 %4 %5 %6 %7 %8 %9 %F90FLAGS%
> %SLINK% %1 %2 %3 %4 %5 %6 %7 %8 %9 %LLIBS% /exe:%~n1.exe
> echo %1.exe created!
> goto END
>
> :MISSING
> echo Missing a filename maybe?
> goto END
>
> :END
> @echo on
>
> The error, upon invoking the script
>
> qwin first.f90 second.f90
>
> is
>
> fatal error LNK1107: invalid or corrupt file: cannot read at 0x46
>
> Does anyone know what could be wrong with it, or has encountered
> anything like that before?
>
> Environment: Windows XP/ifort
>
>
>
> -- Luka

Turn on the echo and look at the linking command that comes out of the
script: it is going to try to link source files, find that the source
files do not have the features expected of .OBJ files, and give up with
loud complaints.

--mecej4

Nasser M. Abbasi <nma@12000.org> wrote:
> On 1/13/2012 7:49 PM, Luka Djigas wrote:
>> I admit, it's been a while since I've last written batch build scripts
>> ... and it shows.

> <snip DOS batch>

> I can't help you with this, as I gave up writing DOS batch scripts
> long time ago.

> My advice is to throw DOS batch scripts away.
> You have much better options these days:

(snip of suggestions)

MS had nmake, more or less an implementation of unix make,
many many years ago. The old MS make wasn't so good, but still
better than a DOS batch file.

Otherwise, I believe that link wants the name without any extension,
or with an .OBJ extension.

The compiler may or may not need an extension. The script looks like
it would work if the compiler didn't, and you didn't put one on
the command line.

-- glen

On Fri, 13 Jan 2012 21:51:17 -0600, "Nasser M. Abbasi" <nma@12000.org>
wrote:

>On 1/13/2012 7:49 PM, Luka Djigas wrote:
>> I admit, it's been a while since I've last written batch build scripts
>> ... and it shows.
>
><snip DOS batch>
>

Uhmm, I'm not using DOS. What made you think that?
cmd in Windows is not DOS.

<snip>

>My advice is to throw DOS batch scripts away. You have much better options
>these days:
>
>1. get cygwin for windows (free), and write all your scripts in a real scripting
>language (bash)
>
>2. get oracle VM box (free), install Linux, mount your windows disk
>from Linux, and and write all your scripts in a real scripting
>language (bash) (this is what I do now).

Unfortunatelly, not only do some of my programs depend on cmd commands,
I also don't like the idea of changing shells/even less an OS, and/or
learning a whole new environment with its inherent set of problems.
My coleagues also probably wouldn't appreciate it much.

As much as I have respect for Linux, my "home" is on Windows for now.


-- Luka

>
>If you work somewhere where they still use DOS for scripts, you
>can educate them to change to Bash.
>
>--Nasser

On Fri, 13 Jan 2012 22:14:58 -0600, mecej4 <mecej4@NOSPAM.operamail.com>
wrote:

>
>Turn on the echo and look at the linking command that comes out of the
>script: it is going to try to link source files, find that the source
>files do not have the features expected of .OBJ files, and give up with
>loud complaints.
>
>--mecej4

Yes, it seems there were two problems. The first one - the linker not
getting files with the .obj extension is now solved.

However, the second still remains.
I have %1 .... %9.

Since I'm passing files to the linker as
%~n1 (<-filename) .obj
in this manner

it results in (if only two files are actually compiled) the linker
being passed a command that looks like this

link first.obj second.obj .obj .obj .obj ...

Do you know perhaps how to avoid this behaviour?
(if %3 does not exist disregard the part that is "attached" to it
%~n3.obj)


-- Luka


p.s. Just for anyone asking, I know there is a make utility for Windows
(a native port), but I find makefiles terribly hard to read. Maybe I'm
just not used to them. And generally they tend to be longer then plain
old batch files.

"Luka Djigas" wrote in message
news:3d03h7la7ci6c17nm82773sitcaikvs5nv@4ax.com...

On Fri, 13 Jan 2012 22:14:58 -0600, mecej4 <mecej4@NOSPAM.operamail.com>
wrote:

>
>Turn on the echo and look at the linking command that comes out of the
>script: it is going to try to link source files, find that the source
>files do not have the features expected of .OBJ files, and give up with
>loud complaints.
>
>--mecej4

Yes, it seems there were two problems. The first one - the linker not
getting files with the .obj extension is now solved.

However, the second still remains.
I have %1 .... %9.

Since I'm passing files to the linker as
%~n1 (<-filename) .obj
in this manner

it results in (if only two files are actually compiled) the linker
being passed a command that looks like this

link first.obj second.obj .obj .obj .obj ...

Do you know perhaps how to avoid this behaviour?
(if %3 does not exist disregard the part that is "attached" to it
%~n3.obj)


-- Luka

----> This should work with a variable number of command line arguments:

for %%f in (%1 %2 %3 %4 %5 %6 %7 %8 %9) do link %%f.obj

-- Elliot

Luka Djigas <ldigas@at.gmail.com> wrote:

(snip)
> Yes, it seems there were two problems. The first one - the linker not
> getting files with the .obj extension is now solved.

> However, the second still remains.
> I have %1 .... %9.

> Since I'm passing files to the linker as
> %~n1 (<-filename) .obj
> in this manner

I believe the linker accepts them without the .OBJ.
It won't accept them with .F90, though.

(I now have the Watcom compiler and linker that I use if I want
to compile/link DOS, Windows, or OS/2 files. It is a much nicer linker
that accepts MS format .OBJ files, and will link them just fine.
It also has a very good overlay system. It also comes with wmake,
which is nicer than MS nmake and make.)

> it results in (if only two files are actually compiled) the linker
> being passed a command that looks like this

> link first.obj second.obj .obj .obj .obj ...

I think you can separately compile them, ignoring the failed messages
for files that don't exist, then link with

LINK %1 %2 %3 %4

But if you want to, you can do something like:

echo off
if exist %9.obj (
echo nine
) else if exist %8.obj (
echo eight
) else if exist %7.obj (
echo seven
) else if exist %6.obj (
echo six
) else if exist %5.obj (
echo five
) else if exist %4.obj (
echo four
) else if exist %3.obj (
echo three
) else if exist %2.obj (
echo two
) else if exist %1.obj (
echo one
) else echo none

Replace each echo with the appropriate LINK command.

(Do HELP IF to see how the IF command works.)

(snip)
> p.s. Just for anyone asking, I know there is a make utility for Windows
> (a native port), but I find makefiles terribly hard to read. Maybe I'm
> just not used to them. And generally they tend to be longer then plain
> old batch files.

Yes they are harder to read, but once you get used to them it
is a lot easier. Among others, many things you don't have to say
over and over. You put a rule that says how to convert a .F90 to
a .OBJ, and it will use that rule unless you specify a different one.

-- glen

On Sat, 14 Jan 2012 14:23:59 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>But if you want to, you can do something like:
>
>echo off
>if exist %9.obj (
>echo nine
>) else if exist %8.obj (
>echo eight
>) else if exist %7.obj (
>echo seven
>) else if exist %6.obj (
>echo six
>) else if exist %5.obj (
>echo five
>) else if exist %4.obj (
>echo four
>) else if exist %3.obj (
>echo three
>) else if exist %2.obj (
>echo two
>) else if exist %1.obj (
>echo one
>) else echo none
>
>Replace each echo with the appropriate LINK command.

Actually wrote it similar to that, in the end. Was hoping for a more
elegant solution though.

>(Do HELP IF to see how the IF command works.)
>
>Yes they are harder to read, but once you get used to them it
>is a lot easier. Among others, many things you don't have to say
>over and over. You put a rule that says how to convert a .F90 to
>a .OBJ, and it will use that rule unless you specify a different one.
>
>-- glen

True. But they got one disadvantage compared to .bat files. You have to
make a .makefile for every program/project you're building. Which, if
you're writing a lot of small programs that you keep all in one
directory, is really not all that practical.

With batch scripts (I have one for command line programs, one for
DISLIN, one for ...) I can just call

build-dislin first.f90 second.f90 third.f90 ... and off it goes.

You probably understand what I'm getting at.


Maybe I'm just not familiar with .makefiles. Can something similar be
accomplished with them too? Also, can they be named differently for
every program you're building - not just .makefile?


-- Luka

In article <2os2h7pc9n4mnnbaupn5v1361908qhoobo@4ax.com>,
Luka Djigas <ldigas@at.gmail.com> wrote:

> Unfortunatelly, not only do some of my programs depend on cmd commands,
> I also don't like the idea of changing shells/even less an OS, and/or
> learning a whole new environment with its inherent set of problems.
> My coleagues also probably wouldn't appreciate it much.

These are exactly the reasons that you should consider programming
in a unix environment. in fact, it is rather odd to hear someone try
to defend a Windows-specific programming environment with that
argument.

This programming environment is the same everywhere, under any
operating system. There is even a POSIX subset environment that is
standardized if that is important. When you restrict yourself to
that, you are virtually guaranteed portability to any modern
computer, now or in the foreseeable future, from laptops to exaflops
supercomputers. Maybe even cell phones should be included in that
list? POSIX is an IEEE industry standard.

> As much as I have respect for Linux, my "home" is on Windows for now.

Linux is certainly popular, but it is not the standard that you
should aim for regarding portability. It is POSIX. This includes,
for example, Linux, AIX, HPUX, MacOSX, SunOS/Solaris, and even
Windows. When you combine POSIX with the various ANSI and ISO
language standards, you have quite a good platform to work with.

Regarding the make utility, yes that is also part of POSIX.
Programmers have a love/hate relationship with make. Anyone (yes I
mean *anyone*) could have designed a better utility than make 30
years ago. But that's not what happened, someone designed make and
it stuck, it is now part of the standard programming environment,
and it will remain so for the foreseeable future. So if you are
interested in becoming a serious programmer, and writing portable
programs that are used by other people, you should invest the effort
to learn how to use it. As quirky as it is, it only takes a few
hours to learn.

$.02 -Ron Shepard

On Sat, 14 Jan 2012 12:06:14 -0600, Ron Shepard
<ron-shepard@NOSPAM.comcast.net> wrote:

>In article <2os2h7pc9n4mnnbaupn5v1361908qhoobo@4ax.com>,
> Luka Djigas <ldigas@at.gmail.com> wrote:
>
>These are exactly the reasons that you should consider programming
>in a unix environment. in fact, it is rather odd to hear someone try
>to defend a Windows-specific programming environment with that
>argument.
>
>This programming environment is the same everywhere, under any
>operating system. There is even a POSIX subset environment that is
>standardized if that is important. When you restrict yourself to
>that, you are virtually guaranteed portability to any modern
>computer, now or in the foreseeable future, from laptops to exaflops
>supercomputers. Maybe even cell phones should be included in that
>list? POSIX is an IEEE industry standard.

Don't take this the wrong way ... but I came here with a linker/batch
build script problem.

Now you're suggesting I change an OS, learn a whole new environment and
change all my hard coded cmd commands in all my programs (that have been
working fine since the time of MS-DOS) ...

doesn't sound like a solution to me.
(though it reminds me of that joke about a fellow buying a boat in the
end

.... not to mention the troubles I'll have when Windows programs try to
read my output files with Unix <eol>'s.

Sorry, not for now ... for what I do, Linux just doesn't cut it (in many
segments).

>Linux is certainly popular, but it is not the standard that you
>should aim for regarding portability. It is POSIX. This includes,
>for example, Linux, AIX, HPUX, MacOSX, SunOS/Solaris, and even
>Windows. When you combine POSIX with the various ANSI and ISO
>language standards, you have quite a good platform to work with.
>
>Regarding the make utility, yes that is also part of POSIX.
>Programmers have a love/hate relationship with make. Anyone (yes I
>mean *anyone*) could have designed a better utility than make 30
>years ago. But that's not what happened, someone designed make and
>it stuck, it is now part of the standard programming environment,
>and it will remain so for the foreseeable future. So if you are
>interested in becoming a serious programmer, and writing portable
>programs that are used by other people, you should invest the effort
>to learn how to use it. As quirky as it is, it only takes a few
>hours to learn.
>

I spend the whole afternoon today trying to figure out can (and how) one
..makefile be used to compile several programs (without hardcoding
anything in the makefile relevant to each of them).
Make that a few days ...


-- Luka

On Sat, 14 Jan 2012 19:27:49 +0100, Luka Djigas <ldigas@at.gmail.com>
wrote:

<snip>
>>programs that are used by other people, you should invest the effort
>>to learn how to use it. As quirky as it is, it only takes a few
>>hours to learn.
>>
>
>I spend the whole afternoon today trying to figure out can (and how) one
>.makefile be used to compile several programs (without hardcoding
>anything in the makefile relevant to each of them).
>Make that a few days ...
>
>
>-- Luka




Had some luck with makefiles. Will give it one more shot to impress.
(but I'm still not switching an OS). Using the one from unxkit-tiny.


-- Luka

p.s. Anyone know how SCons rate for fortran needs? Any (obvious)
advantages over other build systems?

In article <3qh3h7h5jk8nuhrmnafr0a152e2k62cdmn@4ax.com>,
Luka Djigas <ldigas@at.gmail.com> wrote:

> On Sat, 14 Jan 2012 12:06:14 -0600, Ron Shepard
> <ron-shepard@NOSPAM.comcast.net> wrote:
>
> >In article <2os2h7pc9n4mnnbaupn5v1361908qhoobo@4ax.com>,
> > Luka Djigas <ldigas@at.gmail.com> wrote:
> >
> >These are exactly the reasons that you should consider programming
> >in a unix environment. in fact, it is rather odd to hear someone try
> >to defend a Windows-specific programming environment with that
> >argument.
> >
> >This programming environment is the same everywhere, under any
> >operating system. There is even a POSIX subset environment that is
> >standardized if that is important. When you restrict yourself to
> >that, you are virtually guaranteed portability to any modern
> >computer, now or in the foreseeable future, from laptops to exaflops
> >supercomputers. Maybe even cell phones should be included in that
> >list? POSIX is an IEEE industry standard.
>
> Don't take this the wrong way ... but I came here with a linker/batch
> build script problem.
>
> Now you're suggesting I change an OS, learn a whole new environment and
> change all my hard coded cmd commands in all my programs (that have been
> working fine since the time of MS-DOS) ...

Well no, I didn't suggest that you change everything just to solve
your one batch file problem. I just pointed out that your argument
for staying in that environment in the first place was misguided.
There are short term goals and there are long term goals, and
sometimes they are in conflict.

>
> doesn't sound like a solution to me.
> (though it reminds me of that joke about a fellow buying a boat in the
> end
>
> ... not to mention the troubles I'll have when Windows programs try to
> read my output files with Unix <eol>'s.
>
> Sorry, not for now ... for what I do, Linux just doesn't cut it (in many
> segments).

I did not suggest you switch to linux. Maybe you stopped reading
too soon? There are POSIX/unix programming environments within
Windows. Maybe you should consider using one of those in the future?

>
> >Linux is certainly popular, but it is not the standard that you
> >should aim for regarding portability. It is POSIX. This includes,
> >for example, Linux, AIX, HPUX, MacOSX, SunOS/Solaris, and even
> >Windows. When you combine POSIX with the various ANSI and ISO
> >language standards, you have quite a good platform to work with.
> >
> >Regarding the make utility, yes that is also part of POSIX.
> >Programmers have a love/hate relationship with make. Anyone (yes I
> >mean *anyone*) could have designed a better utility than make 30
> >years ago. But that's not what happened, someone designed make and
> >it stuck, it is now part of the standard programming environment,
> >and it will remain so for the foreseeable future. So if you are
> >interested in becoming a serious programmer, and writing portable
> >programs that are used by other people, you should invest the effort
> >to learn how to use it. As quirky as it is, it only takes a few
> >hours to learn.
> >
>
> I spend the whole afternoon today trying to figure out can (and how) one
> .makefile be used to compile several programs (without hardcoding
> anything in the makefile relevant to each of them).
> Make that a few days ...

If you are talking about building a set of small single-file
programs, then here is the usual approach.

..exe.F90:
<place the appropriate commands here>

This defines a "default rule" to build <program>.exe from a single
<program>.F90 file. I don't know what those DOS commands are, but
this should do the trick. If things are more complicated than that,
then of course you need to write specific dependencies for each of
your programs. However, that is not a bad thing because it
describes those dependencies to everyone else who will later build
or modify your programs.

Hope this helps.

$.02 -Ron Shepard

Luka Djigas <ldigas@at.gmail.com> wrote:

(snip, I wrote)
>>But if you want to, you can do something like:

>>if exist %9.obj (
>>echo nine
(snip of eight more cases)

> Actually wrote it similar to that, in the end. Was hoping for a more
> elegant solution though.

CMD isn't as powerful as unix shells, though a little better than
the COMMAND processor for DOS.

I think you can do loops, but I didn't try last night.


(snip on makefiles)

> True. But they got one disadvantage compared to .bat files. You have to
> make a .makefile for every program/project you're building. Which, if
> you're writing a lot of small programs that you keep all in one
> directory, is really not all that practical.

The idea is that the command all go into one makefile for all those
programs.

> With batch scripts (I have one for command line programs, one for
> DISLIN, one for ...) I can just call

> build-dislin first.f90 second.f90 third.f90 ... and off it goes.

> You probably understand what I'm getting at.

Sometimes I make the .cmd file to run make, as it saves just a few
characters of typing.

> Maybe I'm just not familiar with .makefiles. Can something similar be
> accomplished with them too? Also, can they be named differently for
> every program you're building - not just .makefile?

You can name it anything, and use the -f option.

make -f someothermakefile

Note, though, that in the usual case you don't need to do much.

Make knows how to compile programs without any help.

As a test, (on a linux system) I make a file, this.f, and, without
any makefile said

make this

f77 this.f -o this
make: f77: Command not found
make: *** [this] Error 127

So, make figured out how to compile and link the program, but I don't
have f77.

make FC=gfortran this

will do it.

If I make a Makefile with just one line:

FC=gfortran

I can now compile and link any single Fortran file.
There are default rules for that case.

But there is no way that make could know if more files were needed.

Now, add the line:

this: this.o that.o

which tells make to link this.o and that.o to generate that. Or, for DOS:

this.exe: this.obj that.obj

Now make knows to compile both this.f and that.f, but it fails at
link time because it doesn't know that they are gfortran .o files.

If I add

CC=gfortran

So that my Makefile now says:

FC=gfortran
CC=gfortran

this: this.o that.o

It will compile this.f and that.f, then link the two .o files.

Strange as it may seem, the gfortran command will compile C programs.
The cc command will compile, but not successfully link, Fortran
programs.

Anyway, so all you need to add to the Makefile is the dependency
in object files and make will figure out the rest.

Well, you might also need the dependencey for MOD files.

You can set FFLAGS to any compiler options, in the makefile, on
the make command line, or as an environment variable.

-- glen

Luka Djigas <ldigas@at.gmail.com> wrote:

(snip)

> Had some luck with makefiles. Will give it one more shot to impress.
> (but I'm still not switching an OS). Using the one from unxkit-tiny.


Original MS make wasn't much different from a script. It did everything
in the order given, or not.

MS nmake, and unix make, figure out the dependence from the file and
do things in the right order. There is also Watcom's wmake, and,
I believe, ports of GNU make, which has many features not in the
usual unix make.

-- glen