1. Developing MAD-X for Windows

John Jowett

This is a private log of the things I had to do in order to get madX (originally developed on Linux) to work on Windows (using Compaq Visual Fortran and Microsoft Visual C++ in Developer Studio).

Despite being private, this file is visible on the Web.

13/06/2002 14:53:59

Just installed Visual C++ and Visual Fortran on Office PC.

Created madX project in a workspace.

Shortcut to mad-X source on AFS. Must modify one file fulln.c containing explicit AFS paths for includes.

So might as well make my own copy of the source here.

Copied src folder.

Modifed fulln.c by hand in the editor.

Adding all C++ and Fortran files to the source files folder in project.

Discover that extensions for Fortran includes should be .fi or .fd, not .com as HG used.

Problems with error message on all C file compilation

c:\my documents\programming\mad-x\src\matchc.c(529) : fatal error C1010: unexpected end of file while looking for precompiled header directive

Error executing cl.exe.

Confused for now …

After looking at

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/vcrefcompileroptionslistedalphabetically.asp

I found out that I had these pre-compiled header file options set. To get rid of that,

Project/Settings and remove the /Fp and /Yu options and their values.

Now the remaining obstacle is to get access to POSIX functions …

Emailed Marco Cattaneo, some response from Markus Frank but not quite right.

Found something about linker /SUBSYSTEM switch on MSDN, this is presently set to /subsystem:console (Project/Settings/Link ). Try changing to

/subsystem:POSIX

That didn’t work.

27-Aug-04 Tried again with MADX code checked out from repository by CVS. Still having problems with unistd.h.

The C files that are included in madxn.c are now under Resources. Had to use Project Settings to specify that they should not be included in build (otherwise they are compiled by themselves, generating many errors).

Problems in madxd.h

/* short utility routines */

int is_operand(char c) { return (isalnum(c) || c == '_' || c == '.');}

int is_operator(char c) {return (strchr("-+*/^", c) ? 1 : 0);}

int is_expr_start(char c) {return (strchr("-+(",c) || is_operand(c));}

int max(int a, int b) {return (a > b ? a : b);}

int min(int a, int b) {return (a < b ? a : b);}

int str_pos(const char s[], char c)

{unsigned int i; for (i = 0; i < strlen(s); i++) if (s[i] == c) return i; return -1;}

IF I add the unsigned in the last line, one error goes away, but not making this change yet.

27-Aug-04 Trying again: needed to remove include statements from c6t.h to avoid more than one level of including which compiler doesn’t like. Most could be commented out except include c6t.h which I moved up to madxn.c.

Had to put in that unsigned thing again.

/nodefaultlib added to linker options.

/Zm200 to C/C++ options.

/names:lowercase to Fortran options since it complained of not finding Upper case versions of the C routines called in Fortran. However this is still not enough. I still have many errors like

survey.obj : error LNK2001: unresolved external symbol _get_value@16

What to try next ?

/names:lowercase option removed from Fortran settings.

The main problem, I now understand, is that there is no standard way to mix C and Fortran. MAD-X does it in a way which is specific to the compiler used on Linux. Getting it to work on Windows would be easy but we would have to change the way the name-mangling was done and then it wouldn’t work on Linux. So we have to do more complicated things …

Started adding the following

#ifdef _WIN32

!DEC$ ATTRIBUTES C :: get_value

!DEC$ ATTRIBUTES C :: get_variable

!DEC$ ATTRIBUTES C :: double_to_table

!DEC$ ATTRIBUTES C :: advance_node

!DEC$ ATTRIBUTES C :: restart_sequ

!DEC$ ATTRIBUTES C :: node_value

!DEC$ ATTRIBUTES C :: node_vector

!DEC$ ATTRIBUTES C :: augment_count

!DEC$ ATTRIBUTES C :: set_option

#endif

to routines in twiss.f and survey.f that seem to be calling C routines. This seems to be gradually removing the linker errors (still with no \names option in Fortran settings) but is becoming tedious and there are still a lot of things like:

lot.obj : error LNK2001: unresolved external symbol _for_write_seq_lis

trrun.obj : error LNK2001: unresolved external symbol _for_write_seq_lis

twiss.obj : error LNK2001: unresolved external symbol _for_write_seq_lis

util.obj : error LNK2001: unresolved external symbol _for_write_seq_lis

dynap.obj : error LNK2001: unresolved external symbol _for_write_seq_lis

ibsdb.obj : error LNK2001: unresolved external symbol _for_write_seq_lis

match.obj : error LNK2001: unresolved external symbol _for_write_seq_lis

orbf.obj : error LNK2001: unresolved external symbol _for_write_seq_lis

I have not committed these versions of twiss.f and survey.f . Surely there is a better way ... ?

07/04/2003 17:34:16

Spent the last couple of days inserting

#ifdef _WIN32

include 'win32calls.fi'

#endif

in many Fortran program units to take care of the C calls, thus suppressing many linker errors. Found I also had to suppress a block of things like

#define advance_node advance_node_

in madxd.h which seems to be the Unix equivalent.

The call to madx C routine is treated individually in the main Fortran program.

Now I am left with

--------------------Configuration: madX - Win32 Debug--------------------

Linking...

trrun.obj : error LNK2001: unresolved external symbol _for_write_seq_lis

twiss.obj : error LNK2001: unresolved external symbol _for_write_seq_lis

util.obj : error LNK2001: unresolved external symbol _for_write_seq_lis

dynap.obj : error LNK2001: unresolved external symbol _for_write_seq_lis

ibsdb.obj : error LNK2001: unresolved external symbol _for_write_seq_lis

match.obj : error LNK2001: unresolved external symbol _for_write_seq_lis

orbf.obj : error LNK2001: unresolved external symbol _for_write_seq_lis

trrun.obj : error LNK2001: unresolved external symbol _for_write_seq_lis_xmit

util.obj : error LNK2001: unresolved external symbol _for_write_seq_lis_xmit

dynap.obj : error LNK2001: unresolved external symbol _for_write_seq_lis_xmit

ibsdb.obj : error LNK2001: unresolved external symbol _for_write_seq_lis_xmit

match.obj : error LNK2001: unresolved external symbol _for_write_seq_lis_xmit

orbf.obj : error LNK2001: unresolved external symbol _for_write_seq_lis_xmit

twiss.obj : error LNK2001: unresolved external symbol __FIsqrt

util.obj : error LNK2001: unresolved external symbol __FIsqrt

orbf.obj : error LNK2001: unresolved external symbol __FIsqrt

survey.obj : error LNK2001: unresolved external symbol __FIsqrt

trrun.obj : error LNK2001: unresolved external symbol __FIsqrt

dynap.obj : error LNK2001: unresolved external symbol __FIsqrt

emit.obj : error LNK2001: unresolved external symbol __FIsqrt

ibsdb.obj : error LNK2001: unresolved external symbol __FIsqrt

match.obj : error LNK2001: unresolved external symbol __FIsqrt

util.obj : error LNK2001: unresolved external symbol __FIsin

dynap.obj : error LNK2001: unresolved external symbol __FIsin

emit.obj : error LNK2001: unresolved external symbol __FIsin

trrun.obj : error LNK2001: unresolved external symbol __FIsin

twiss.obj : error LNK2001: unresolved external symbol __FIsin

trrun.obj : error LNK2001: unresolved external symbol __FIlog

dynap.obj : error LNK2001: unresolved external symbol __FIlog

emit.obj : error LNK2001: unresolved external symbol __FIlog

ibsdb.obj : error LNK2001: unresolved external symbol __FIlog

util.obj : error LNK2001: unresolved external symbol __FIcos

dynap.obj : error LNK2001: unresolved external symbol __FIcos

emit.obj : error LNK2001: unresolved external symbol __FIcos

trrun.obj : error LNK2001: unresolved external symbol __FIcos

twiss.obj : error LNK2001: unresolved external symbol __FIcos

dynap.obj : error LNK2001: unresolved external symbol __FIatan

dynap.obj : error LNK2001: unresolved external symbol __FIasin

twiss.obj : error LNK2001: unresolved external symbol __FIasin

emit.obj : error LNK2001: unresolved external symbol __FIatan2

survey.obj : error LNK2001: unresolved external symbol __FIatan2

twiss.obj : error LNK2001: unresolved external symbol __FIatan2

trrun.obj : error LNK2001: unresolved external symbol _for_write_seq_fmt

twiss.obj : error LNK2001: unresolved external symbol _for_write_seq_fmt

util.obj : error LNK2001: unresolved external symbol _for_write_seq_fmt

emit.obj : error LNK2001: unresolved external symbol _for_write_seq_fmt

ibsdb.obj : error LNK2001: unresolved external symbol _for_write_seq_fmt

match.obj : error LNK2001: unresolved external symbol _for_write_seq_fmt

orbf.obj : error LNK2001: unresolved external symbol _for_write_seq_fmt

trrun.obj : error LNK2001: unresolved external symbol _for_write_seq_fmt_xmit

twiss.obj : error LNK2001: unresolved external symbol _for_write_seq_fmt_xmit

util.obj : error LNK2001: unresolved external symbol _for_write_seq_fmt_xmit

emit.obj : error LNK2001: unresolved external symbol _for_write_seq_fmt_xmit

ibsdb.obj : error LNK2001: unresolved external symbol _for_write_seq_fmt_xmit

match.obj : error LNK2001: unresolved external symbol _for_write_seq_fmt_xmit

orbf.obj : error LNK2001: unresolved external symbol _for_write_seq_fmt_xmit

emit.obj : error LNK2001: unresolved external symbol __FItan

twiss.obj : error LNK2001: unresolved external symbol __FItan

emit.obj : error LNK2001: unresolved external symbol _dpowi

ibsdb.obj : error LNK2001: unresolved external symbol _dpowi

twiss.obj : error LNK2001: unresolved external symbol _dpowi

ibsdb.obj : error LNK2001: unresolved external symbol __OtsMove

trrun.obj : error LNK2001: unresolved external symbol __OtsMove

twiss.obj : error LNK2001: unresolved external symbol __OtsMove

ibsdb.obj : error LNK2001: unresolved external symbol _for_stop_core

orbf.obj : error LNK2001: unresolved external symbol _for_stop_core

util.obj : error LNK2001: unresolved external symbol _for_stop_core

ibsdb.obj : error LNK2001: unresolved external symbol __FIalog10

ibsdb.obj : error LNK2001: unresolved external symbol __FIIfexp_

madxm.obj : error LNK2001: unresolved external symbol _for_check_flawed_pentium@0

madxm.obj : error LNK2001: unresolved external symbol _for_set_reentrancy@4

madxn.obj : error LNK2001: unresolved external symbol __chkesp

madxn.obj : error LNK2001: unresolved external symbol _printf

madxn.obj : error LNK2001: unresolved external symbol _puts

madxn.obj : error LNK2001: unresolved external symbol __fltused

madxn.obj : error LNK2001: unresolved external symbol _exit

madxn.obj : error LNK2001: unresolved external symbol __pctype

madxn.obj : error LNK2001: unresolved external symbol __isctype

madxn.obj : error LNK2001: unresolved external symbol ___mb_cur_max

madxn.obj : error LNK2001: unresolved external symbol _strchr

madxn.obj : error LNK2001: unresolved external symbol _strlen

madxn.obj : error LNK2001: unresolved external symbol _strcpy

madxn.obj : error LNK2001: unresolved external symbol _strcmp

madxn.obj : error LNK2001: unresolved external symbol _free

madxn.obj : error LNK2001: unresolved external symbol _sscanf

madxn.obj : error LNK2001: unresolved external symbol _strcat

madxn.obj : error LNK2001: unresolved external symbol _fabs

madxn.obj : error LNK2001: unresolved external symbol _strstr

madxn.obj : error LNK2001: unresolved external symbol __ftol

madxn.obj : error LNK2001: unresolved external symbol _sprintf

madxn.obj : error LNK2001: unresolved external symbol _strncmp

madxn.obj : error LNK2001: unresolved external symbol _tolower

madxn.obj : error LNK2001: unresolved external symbol _fprintf

madxn.obj : error LNK2001: unresolved external symbol _fopen

madxn.obj : error LNK2001: unresolved external symbol _setbuf

madxn.obj : error LNK2001: unresolved external symbol __iob

madxn.obj : error LNK2001: unresolved external symbol _pow

madxn.obj : error LNK2001: unresolved external symbol _sqrt

madxn.obj : error LNK2001: unresolved external symbol _setup_

madxn.obj : error LNK2001: unresolved external symbol _sin

madxn.obj : error LNK2001: unresolved external symbol _cos

madxn.obj : error LNK2001: unresolved external symbol _micit_

madxn.obj : error LNK2001: unresolved external symbol _haveit_

madxn.obj : error LNK2001: unresolved external symbol _ftime

madxn.obj : error LNK2001: unresolved external symbol _malloc

madxn.obj : error LNK2001: unresolved external symbol _calloc

madxn.obj : error LNK2001: unresolved external symbol _strncpy

madxn.obj : error LNK2001: unresolved external symbol _fclose

madxn.obj : error LNK2001: unresolved external symbol _strtok

madxn.obj : error LNK2001: unresolved external symbol _fgets

madxn.obj : error LNK2001: unresolved external symbol _abs

madxn.obj : error LNK2001: unresolved external symbol _mtsimp_

madxn.obj : error LNK2001: unresolved external symbol _mtmigr_

madxn.obj : error LNK2001: unresolved external symbol _mtlmdf_

madxn.obj : error LNK2001: unresolved external symbol _collect_

madxn.obj : error LNK2001: unresolved external symbol _mtgeti_

madxn.obj : error LNK2001: unresolved external symbol __chkstk

madxn.obj : error LNK2001: unresolved external symbol _log

madxn.obj : error LNK2001: unresolved external symbol _isatty

madxn.obj : error LNK2001: unresolved external symbol _toupper

madxn.obj : error LNK2001: unresolved external symbol _localtime

madxn.obj : error LNK2001: unresolved external symbol _time

madxn.obj : error LNK2001: unresolved external symbol _system

madxn.obj : error LNK2001: unresolved external symbol _gxterm_

madxn.obj : error LNK2001: unresolved external symbol _tanh

madxn.obj : error LNK2001: unresolved external symbol _cosh

madxn.obj : error LNK2001: unresolved external symbol _sinh

madxn.obj : error LNK2001: unresolved external symbol _atan

madxn.obj : error LNK2001: unresolved external symbol _acos

madxn.obj : error LNK2001: unresolved external symbol _asin

madxn.obj : error LNK2001: unresolved external symbol _tan

madxn.obj : error LNK2001: unresolved external symbol _log10

madxn.obj : error LNK2001: unresolved external symbol _exp

madxn.obj : error LNK2001: unresolved external symbol _emit_

madxn.obj : error LNK2001: unresolved external symbol _getclor_

madxn.obj : error LNK2001: unresolved external symbol _tmrefe_

madxn.obj : error LNK2001: unresolved external symbol _ibs_

madxn.obj : error LNK2001: unresolved external symbol _survey_

madxn.obj : error LNK2001: unresolved external symbol _twiss_

madxn.obj : error LNK2001: unresolved external symbol _atof

madxn.obj : error LNK2001: unresolved external symbol _atoi

madxn.obj : error LNK2001: unresolved external symbol _dynap_

madxn.obj : error LNK2001: unresolved external symbol _trrun_

madxn.obj : error LNK2001: unresolved external symbol _tmrefo_

orbf.obj : error LNK2001: unresolved external symbol _locf

trrun.obj : error LNK2001: unresolved external symbol __OtsFill

twiss.obj : error LNK2001: unresolved external symbol __OtsFill

util.obj : error LNK2001: unresolved external symbol __OtsFill

trrun.obj : error LNK2001: unresolved external symbol __OtsStringCompareEqlPadded

util.obj : error LNK2001: unresolved external symbol __OtsStringCompareEqlPadded

trrun.obj : error LNK2001: unresolved external symbol _for_write_int_fmt

twiss.obj : error LNK2001: unresolved external symbol _for_write_int_fmt

trrun.obj : error LNK2001: unresolved external symbol __FIexp

twiss.obj : error LNK2001: unresolved external symbol __FIexp

trrun.obj : error LNK2001: unresolved external symbol _for_write_int_fmt_xmit

twiss.obj : error LNK2001: unresolved external symbol _for_write_int_fmt_xmit

twiss.obj : error LNK2001: unresolved external symbol __OtsMoveMinimum

util.obj : error LNK2001: unresolved external symbol __OtsMoveMinimum

twiss.obj : error LNK2001: unresolved external symbol _ipowi

twiss.obj : error LNK2001: unresolved external symbol __FIcosh

util.obj : error LNK2001: unresolved external symbol __FIcosh

twiss.obj : error LNK2001: unresolved external symbol __FIsinh

util.obj : error LNK2001: unresolved external symbol __FIsinh

util.obj : error LNK2001: unresolved external symbol __FIanint

LINK : error LNK2001: unresolved external symbol _mainCRTStartup

Debug/madX.exe : fatal error LNK1120: 104 unresolved externals

Error executing link.exe.

madX.exe - 169 error(s), 0 warning(s)

I have found that most of these missing externals are in

Program Files\Microsoft Visual Studio\DF98\LIB\DFOR.LIB

which seems to be on Tools/Options/Directories then Library Files in CVF as it should be. What is wrong ?

http://dbforums.com/arch/132/2002/10/542043 http://home.online.no/~arnholm/cppf77.htm

Unchecking Project/Settings/Linker/ Ignore all default libraries gets rid of a lot of above. The remaing unresolved externals seem to be the Fortran routines called by C in madX.

The Mathematica notebook FixSourceFiles.nb is very helpful here.

Going by my speak.f file in the prototype project basicf1.dsw, now all I have to do is add a

!DEC$ ATTRIBUTES C :: subroutinename

to each of these routines.s

But I am having trouble with clipboard so reboot now.

08/04/2003 08:33:57

Seems like the kind of line I need in the Fortran routines that get called from C is

#ifdef _WIN32

!DEC$ ATTRIBUTES C, ALIAS:'_setup_' :: setup

#endif

08/04/2003 09:19:11

I thought I had done it before but I have just removed the gxx11* files from the project. This is stuff for making Unix screen graphics.

Just rediscovered why several C files are in the “Resource Files” folder of the project: they should not be compiled themselves but are included in madxn.c (bad practice). Make sure they are not included in build (right-click file, Settings …).

08/04/2003 09:58:19

Now, apart from a lot of compile warnings like:

Compiling Fortran...

util.i

F:\Programming\mad-X\src\madX\util.f(1679) : Warning: Variable NN is used before its value has been defined

call get_node_vector('knl ',nn,normal)

------^

all I have to deal with are linker errors:

Linking...

LINK : warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs; use /NODEFAULTLIB:library

match.obj : error LNK2001: unresolved external symbol _MTGETI@12

orbf.obj : error LNK2001: unresolved external symbol _locf

Debug/madX.exe : fatal error LNK1120: 2 unresolved externals

Error executing link.exe.

Creating browse info file...

madX.exe - 3 error(s), 60 warning(s)

I think these are cases where a Fortran program unit is called from both C and Fortran.

Tried following the warning about the library in

so the Project Options box now contains:

kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /incremental:yes /pdb:"Debug/madX.pdb" /debug /machine:I386 /nodefaultlib:"LIBCD.lib" /out:"Debug/madX.exe" /pdbtype:sept

and that gets us down to

------------------Configuration: madX - Win32 Debug--------------------

Linking...

match.obj : error LNK2001: unresolved external symbol _MTGETI@12

orbf.obj : error LNK2001: unresolved external symbol _locf

Debug/madX.exe : fatal error LNK1120: 2 unresolved externals

Error executing link.exe.

madX.exe - 3 error(s), 0 warning(s)

08/04/2003 17:44:51

Finished the compiling and linking earlier this afternoon. It starts to run but crashes in either TWISS or SURVEY.

10/04/2003 10:04:15

Discussed committing my changes with Frank Schmidt yesterday afternoon. He suggests waiting for now until I have something that works completely. Apparently the Unix compiler will not accept #ifdef stuff in .f files so they will all have to be changed to .fpp and he’s not too keen on that change (true, it’s a pain for CVS). Should also discuss with Werner Herr and Oliver about the things I had to do to their parts.

Identified remaining problem as due to bad transfer of string data when Fortran calls C routines. FS sent me a toy program (Fstoy) to do this. I got it working with the change to the DEC line

!DEC$ ATTRIBUTES C,REFERENCE :: myc

I have added the REFERENCE attribute in my win32calls.fi file.

Still having some trouble with this, seems as if the second string argument of get_value is not passed. Trying the

/iface:nomixed_str_len_arg option for Fortran compiler.

10/04/2003 12:19:21

The debug version successfully ran the SURVEY test a little while ago. Trying for a Release version:

http://dbforums.com/arch/132/2002/4/360946 contained useful hints:

Tzu Yi Yu
Apr 24 2002 3:03

Dear All:

I use MicorSoft Visual Fortran to write an application, the problem I have is that
I don't know how to add something like:

#ifdef FALG ........ #else ....... #endif

to the fortran code. Well, I did add it, but when I compile it, it has the warning
message, saying "Bad # preprocessor line". I try change the .f to .f90, the situation
is the same. How can I solve this problem?

Thanks for all helps and suggestions.

Steve Lionel
Apr 24 2002 3:04

On 4 Apr 2002 15:37:16 GMT, tyyu@erc.msstate.edu (Tzu Yi Yu) wrote:

> I use MicorSoft Visual Fortran to write an application, the problem I have is that
> I don't know how to add something like:
>
>#ifdef FALG ........ #else ....... #endif
>

There is no such product as Microsoft Visual Fortran. If you have Compaq (or Digital)
Visual Fortran, you should select Project..Settings..Fortran..Preprocessor and check
the Enable FPP box. On the command line, this is /fpp. See the Visual Fortran
Programmer's Guide for more information.

Now I have to get past:

:\Programming\mad-X\src\madX\orbf.fpp(1833) : Warning: Variable LGFILE is used before its value has been defined

if(lgfile .eq. 0) then

-----------^

which points to a line in madxdict.h.

Is this a compiler option for C ? Looking for it.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_core_.2f.zm.asp

10/04/2003 12:35:16

Added /Zm200 to the C compilation options. Makes a program that runs but crashes again in SURVEY,.

Still crashing.

10/04/2003 14:25:15

I had to add the /iface:nomixed_str_len_arg option to the Release version. Now it seems to run too.

The system command works as expected.

system,”notepad”;

Looks good. Tried toy survey and RHIC examples. Seem OK.

23/04/2003 17:36:50

Found that TWISS was not working properly - so there are still problems to solve.

2. First commit of the Windows version to the repository

25/04/2003 17:28:45

I just committed the Windows version with the comment “Win32 Version.” Not all files were changed so some were not included in the commit.

Before I did this Frank Schmidt had processed all the files containing tab characters and trailing blanks. In most cases his processing of tab characters was equivalent to the KEDIT commands:

SET TABS 7 INCR 1

EXPAND *

After doing that, the many spurious differences between my files and the new ones in the repository mostly disappeared. There were some special cases to take care of manually though.

Some things we learned this afternoon:

· Although I have KEDIT set up to use Unix style linend characters, WinCVS creates files with DOS line-ends, e.g., when I update a file with the repository. We were alarmed at first when I copied files to AFS so that Frank could compare them over there. They acquire DOS lineends. However, if we copy them via the repository, there is no problem: CVS checks them out with Unix line-ends on Unix systems! Moral: DO NOT copy files that are under CVS control directly between systems (via the AFS client, for example).

· I might as well set KEDIT up not to use Unix line-ends while I am doing this kind of work. However it doesn’t really matter as long as I do an update from CVS.

I have recompiled the Release version to include other people’s changes: putting that on the Web.

FS tells me that all the *.f files are going to have to be changed to *.F (because one of the Unix compilers doesn’t allow compiler directives in plain .f files). I hope that will be OK with Windows.

2.1. Attempt to compile another version

5/06/2003 11:20:24

I have been trying to compile the latest MAD-X on Windows. I have an error that occurs 3 times in the file madxu.c, apparently because of recent changes.

f:\programming\mad-x\src\madx\madxu.c(1963) : error C2036: 'void *' : unknown size

The error occurs in the lines marked in red in the following functions:

void* mycalloc(char* caller, size_t nelem, size_t size)

  /* calls calloc, checks for memory granted */

  void* p;

  int* i_p;

  size_t l_size = nelem*size + sizeof(int);

  if ((p = calloc(1, l_size)) == NULL)

     fatal_error("memory overflow, called from routine:", caller);

  i_p = (int*) p; *i_p = FREECODE;

  return (p+sizeof(int));

void myfree(char* rout_name, void* p)

  char* l_p = p - sizeof(int);

  int* i_p = (int*) l_p;

  myfree_caller = rout_name;

  if (*i_p == FREECODE)

   *i_p = 0; free(l_p);

  myfree_caller = none;

void* mymalloc(char* caller, size_t size)

  /* calls malloc, checks for memory granted */

  void* p;

  int* i_p;

  size_t l_size = size + sizeof(int);

  if ((p = malloc(l_size)) == NULL)

    fatal_error("memory overflow, called from routine:", caller);

  i_p = (int*) p; *i_p = FREECODE;

  return (p+sizeof(int));

It seems that the use of 'p' in these assignments causes the problem since it was declared as void *. I don't really understand this stuff so I don't have any ideas for fixing it.

Except that in Stroustrup Appendix B.2.2, I found:

In C, a void* may may used as the right-hand operand of an assignment to or initialization of a variable of any pointer type; in C++ it may not.

It could be that the compiler is behaving like C++ in this respect although it is supposed to treat .c files as C. I'm not sure.

13/06/2003 14:09:45

Yesterday, FS told me that HG had confirmed that this is indeed C++ like behaviour but a small fix to the code now allows me to compile. I have created both Debug and Release versions. They both seem to run but I have not made many tests yet. I will put them on Web, still as Beta versions.

16/07/2003 13:51:19

A reply to a mail of mine:

From: Frank SCHMIDT [Frank.Schmidt@cern.ch]

Sent: Tuesday, 15 July, 2003 12:31

To: John.Jowett@cern.ch

Subject: Re: MAD-X error

Categories: CERN SpamKiller Note: -51

Hi John,

here are again the old and new version and I cannot really see a problem

since the void part looks the same???

Old version V1.11:

void* mycalloc(char* caller, size_t nelem, size_t size)

{

/* calls calloc, checks for memory granted */

void* p;

if ((p = calloc(nelem, size)) == NULL)

fatal_error("memory overflow, called from routine:", caller);

return p;

}

New version V1.12:

void* mycalloc(char* caller, size_t nelem, size_t size)

{

/* calls calloc, checks for memory granted */

void* p;

int* i_p;

size_t l_size = nelem*size + sizeof(int);

if ((p = calloc(1, l_size)) == NULL)

fatal_error("memory overflow, called from routine:", caller);

i_p = (int*) p; *i_p = FREECODE;

return ((char*)p+sizeof(int));

}

Maybe you want to cast the return value to (void *) ??

return (void *)((char*)p+sizeof(int));

Agreed, all this strange casting does not look very sane to me either...

Cheers, Frank

So I made that change and have committed madxu.c.

Found a problem with Unix version: all particles getting lost on the LHCSCREEN type aperture. This is a major logic bug in ttrun.f. But AV will be away till end August and we need this now. Fixed it myself and committed in agreement with FS. Here is my modified code:

!------------  LHC screen case ----------------------------------

        else if(aptype.eq.'lhcscreen') then

!        print *, "LHC screen start, Xrect= ",

!     &  aperture(1),"  Yrect= ",aperture(2),"  Rcirc= ",aperture(3)

          apx = aperture(3)

          apy = aperture(3)

!JMJ!     Making essential changes in AV's absence, 16/7/2003

!JMJ!     this tests whether the particle is outside the circumscribing

!JMJ!     circle.

          call trcoll(1, apx, apy, turn, sum, part_id, last_turn,       &

     &    last_pos, last_orbit, track, ktrack,al_errors)

!JMJ!

!JMJ!     This tests whether particles are outside the space bounded by

!JMJ!     two or four lines intersecting the circle.

!JMJ!     The previous version checked that it was outside a rectangle,

!JMJ!     one of whose dimensions was zero (in the LHC) so particles

!JMJ!     were ALWAYS lost on the beam screen.

!JMJ!     The new version of the test works on the understanding that

!JMJ!     values of aperture(1) or aperture(2) greater than aperture(3)

!JMJ!     have no meaning and that specifying a zero value is equivalent.

!JMJ!     The most general aperture described by the present

!JMJ!     implementation of LHCSCREEN is a rectangle with rounded

!JMJ!     corners.

!JMJ!     N.B. apx and apy already have the value aperture(3); the "if"s

!JMJ!     ensure that they don't get set to zero.

          if(aperture(1).gt.0.) apx = aperture(1)

          if(aperture(2).gt.0.) apy = aperture(2)

          call trcoll(2, apx, apy, turn, sum, part_id, last_turn,       &

     &    last_pos, last_orbit, track, ktrack,al_errors)

!        print *, "LHC screen end"

For the moment I can’t compile on Windows because it seems (not sure but FS suggested this …) there have been substantial changes (orbF.F, madxc.c, I think) by starting from a private copy of the files and not merging including earlier changes that I made (so much for CVS discipline…). So I have to do them again.

A couple of days ago, FS said he would really like Windows version to have the MAD graphics again. This should be possible at least as far as making EPS output files goes (just like the Windows MAD-8). However I took a look and it is not obvious how to switch that on again. I emailed HG for advice yesterday. However I don’t care myself since there are plenty of other ways to plot MAD tables.

26/08/2004 20:03:48 Some time since I last made a note here. In the meantime, FS bought the Lahey Fortran 95 compiler for both Linux and Windows and found that the same code would compile on both systerms. So the last few versions of MAD-X distributed have been made with that compiler and seem to work fine. All the struggle recorded above seemed to be somewhat in vain and FS even took out some of the modifications I had made because (it seemed …) that the Windows Lahey compiler could not work with ifdef directives (however that seems to have been a red herring).

Now, however, it turns out we want to go back to the Compaq Fortran compiler because there is no decent development environment like Visual Studio for Lahey. And people at SLAC want to contribute to MAD-X in this framework.

First problem: the _WIN32 directive that I used is system defined and also applies for Lahey. So I have changed _WIN32 to _VFWIN32 throughout the code. Seems to compile OK.

Next problem: there is one routine, gxterm now, that is called from both C and Fortran so needs the special treatment I had already given to mtgeti in match.F, i.e., make a dummy duplicate for calling from C only. Or so FS said. But as far as I can tell, gxterm is only called from C,

Searching for 'gxterm'...

F:\MAD\MADX_TREE\MADX_TREE\madxd.h(93):extern void gxterm_();

F:\MAD\MADX_TREE\MADX_TREE\madxn.c(3221): /* gxterm_();*/

2 occurrence(s) have been found.

That was a search in C filetypes. In Fortran filetypes we have

Searching for 'gxterm'...

F:\MAD\MADX_TREE\MADX_TREE\gxx11ps.F(6490): subroutine gxterm

F:\MAD\MADX_TREE\MADX_TREE\gxx11ps.F(6492):!!!!!!!!!!! !DEC$ ATTRIBUTES C, ALIAS:'_gxterm_' :: gxterm

F:\MAD\MADX_TREE\MADX_TREE\plot.F(2716):! calls the routines gxsvar, gxterm, gxinit, gxopen, gxwait, gxclrw and

F:\MAD\MADX_TREE\MADX_TREE\plot.F(2760): call gxterm

4 occurrence(s) have been found.

27/08/2004 10:00:06

I have now added a duplicate gxtermc Fortran routine that does exactly the same as gxterm but can be called from C. gxterm should only be called from Fortran. All in the file gx11ps.F, done by analogy with mgeti/mtgetc in match.F but must also make an entry in madxd.h.

Uncommented the call to gxterm, now gxtermc in madxn.c. Seems to compile and run OK

Tried P:\cern.ch\eng\sl\MAD-X\pro\test_runs\example\andre.mad example which works with present production version.

Crashes with

survey,psi0=0.0,file="prtsurv";

enter Survey module

forrtl: severe (157): Program Exception - access violation

Image PC Routine Line Source

madx.exe 004604CE Unknown Unknown Unknown

madx.exe 004770BE Unknown Unknown Unknown

madx.exe 004D0CDE Unknown Unknown Unknown

madx.exe 0047DD9A Unknown Unknown Unknown

madx.exe 0046E239 Unknown Unknown Unknown

madx.exe 0047C249 Unknown Unknown Unknown

madx.exe 0047D68C Unknown Unknown Unknown

madx.exe 00478308 Unknown Unknown Unknown

madx.exe 0046DB04 Unknown Unknown Unknown

madx.exe 00469D8A Unknown Unknown Unknown

madx.exe 0046DEB5 Unknown Unknown Unknown

madx.exe 0047C249 Unknown Unknown Unknown

madx.exe 0047D68C Unknown Unknown Unknown

madx.exe 00478308 Unknown Unknown Unknown

madx.exe 004359C9 Unknown Unknown Unknown

madx.exe 00435983 Unknown Unknown Unknown

madx.exe 005517F9 Unknown Unknown Unknown

madx.exe 00544B35 Unknown Unknown Unknown

kernel32.dll 77E814C7 Unknown Unknown Unknown

Incrementally linked image--PC correlation disabled.

Press any key to continue

Although simple commands (HELP,VALUE … ) seem OK.

Is this my problem ?

27/08/2004 15:15:44

Trying to remove some cl.exe options. This is what we had:

Copy the text to:

/nologo /MLd /W3 /Gm /GX /ZI /Od /D "_WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /D "_VFWIN32" /FR"Debug/" /Fp"Debug/madx.pch" /YX /Fo"Debug/" /Fd"Debug/" /FD /Zm1000 /GZ /c

OK …

Tried getting rid of various things, right down to

but it does not solve the problem so I have put the original options back.

Exported a makefiile to check that the C compiler in use is really cl.exe, as for Lahey.

Leaving it in FS’s hands now.