Experimental Physics and
Industrial Control System

"Johnson, Andrew N." <[email protected]> · Tue, 19 May 2015 04:01:40 +0000

Hi Ben,

On May 18, 2015, at 6:58 AM, Benjamin Franksen <[email protected]> wrote:

> On Thursday 30 April 2015 17:47:43 Mark Rivers wrote:
>> -    Added this line
>>     -include $(TOP)/../configure/EPICS_BASE.$(EPICS_HOST_ARCH)
>>     That line is very helpful when building synApps, since it allows
>> a top-level configure/EPICS_BASE.$(EPICS_HOST_ARCH) define a
>> different path to EPICS base depending on the architecture. Useful
>> when building Windows and Linux in the same tree.
> 
> I would like to hear more opinions about this point before applying this
> change to the sequencer.
> 
> It seems to me that everyone is using their own self-written meta build
> system (for building sets of interdependent modules, sometimes including
> base). Supporting the one that is used in synApps in the way you propose
> makes certain assumptions about where in the file system the sequencer
> is installed relative to other modules. In particular,
> $(TOP)/../configure/ could theoretically collide with some other
> module's configure directory.

That collision would only occur if a user were to embed (install) the sequencer as a subdirectory inside the other module, which IMHO is more likely to be the kind of case where they would /want/ to be able to inherit settings from the parent module, especially for the path to Base itself. The $(TOP)/../configure/ convention is synApps’ fairly simple approach to reducing the amount of work for its users. If this breaks some other site’s installation then they can fix it by removing the -include line from the synApps RELEASE file (which they have to edit anyway) when they install it; they will have to do that for any other synApps modules too since most of them already have this line.

>> examples/demo/Makefile
>> 
>> -    This needed to be changed to build on cygwin-x86.  All symbols
>> that are imported because of a dbd file (i.e, function(),
>> registrar(), etc.) must be in a library, they cannot be built
>> directly into a main program.  Andrew Johnson can explain this
>> further if you have questions.
>> 
>> src/seq/Makefile
>> src/seq_main.c
>> src/seq_prim_types.c (new file)
>> src/seq_prim_types.h
>> src/snc/var_types.c
> 
> Andrew, if you are reading this, I would be very interested to hear
> more. Besides, I may have misunderstood this but didn't you write that
> EPICS will stop supporting cygwin anyway?

I did not write that we were dropping Cygwin, Ralph and Michael were discussing the possibility a few weeks ago, but I fixed the bug that was causing the problem, and the fact that Mark needs it tells me that we couldn’t afford to drop it anyway.

The issue is related to name decorations, which are described in comments in shareLib.h The ioc_registerRecordDeviceDriver.cpp file generated from an ioc.dbd file decorates the names of the external symbols read from the DBD file with epicsShareExtern; epicsExportSharedSymbols is not defined when these macros are used. Thus when compiling this file on Windows with SHARED_LIBRARIES=YES the epicsShareExtern macro expands to __declspec(dllimport) extern, telling the compiler these symbols will be imported from a DLL.

The matching symbols must also have been decorated with epicsShareExtern but with epicsExportSharedSymbols defined, so the macro expands to __declspec(dllexport) extern. This is normally hidden by the epicsExport.h header and the epicsExportAddress() macro. If you try to define those symbols in the same executable as the registerRecDevDriver code, the linker will not be able to match up the decorated names and the link will fail.

Now the Microsoft linker seems to have been made somewhat more forgiving in recent versions such that when it can’t match up the symbols it checks the names decorated differently and silently accepts incorrect decorations, but in Cygwin (and probably in MinGW builds too) the GNU linker doesn’t do that. Thus if you want your code to build on Cygwin you have to get your decorations right and you can’t mix-and-match between code compiled for a DLL and code meant for directly linking into an executable.

>> -    The way that prim_types was being handled does not work on
>> win32-x86, windows-x64, or cygwin-x86.  Following Andrew Johnson's
>> suggestion I left only the structure definitions in seq_prim_types.h
>> (with epicsShareExtern) and moved the value assignments into the new
>> seq_prim_types.c file.  This works fine, and also cleans up
>> seq_main.c and var_types.c.
> 
> I have picked up this pattern from EPICS base sources where it is used
> in several places and is documented in shareLib.h. I don't understand
> why it works in base but not in the sequencer.

Some older versions of Base would not build on Cygwin with SHARED_LIBRARIES=YES, we just ignored the errors and said “don’t try that”. I fixed the problems in Base the same way Mark is recommending here.

>> On win32-x86-static and windows-x64-static many of the tests
>> succeeded, but in both cases it hung up in bittypeIoc.t.  I had to
>> kill them with ^C.
>> 
>> bittypesIoc.t .......... Starting iocInit
>> iocRun: All initialization complete
>> bittypesIoc.t .......... 1/24 ERROR: The process "softIoc.exe" not
>> found. Terminating on signal SIGINT(2)
>> Terminating on signal SIGINT(2)
>> make[2]: *** [runtests.win32-x86-static] Error 130
>> make[1]: *** [validate.runtests] Error 130
>> make: *** [test.runtests] Error 130
>> 
>> bittypesIoc.t .......... Starting iocInit
>> bittypesIoc.t .......... 1/24 cas warning: Configured TCP port was
>> unavailable. cas warning: Using dynamically assigned TCP port 65113,
>> cas warning: but now two or more servers share the same UDP port.
>> cas warning: Depending on your IP kernel this server may not be
>> cas warning: reachable with UDP unicast (a host's IP in
>> EPICS_CA_ADDR_LIST) iocRun: All initialization complete
>> Terminating on signal SIGINT(2)
> 
> This happens often when running the tests immediately after building.
> Normally it works fine when you run the tests again.
> 
> I have not yet found what causes these hangups. There must be some
> subtle interaction between the Perl/system/exec/kill stuff and what the
> IOC in the background does.

Seems vaguely familiar, but I can’t think why. I’ll let you know if I remember anything.
Ah, you don’t use ‘exec’ in your test scripts to run other programs do you? If you do, GNUmake on Windows thinks the Perl script has finished executing as soon as the Perl program goes away even if it successfully started that other program. My makeTestfile.pl script now uses this code to pick the command in the .t files that run other programs:

  # Use system on Windows, exec doesn't work the same there and
  # GNUmake thinks the test has finished as soon as Perl exits.
  my $exec = $^O eq 'MSWin32' ? "system('./$exe') == 0" : "exec './$exe'";

>> The other 3 architectures (all dynamic) failed to run any tests
>> because seq.dll was not found when trying to run the executables.
>> The EPICS build system creates an IOC file called dllPath.bat, which
>> can be used to define the PATH to find all of the required DLLs.
>> This needs to be somehow incorporated into the test harness.
> 
> OMG.
> 
> Andrew, do you have any suggestions how to proceed? Is this documented
> somewhere?

The dllPath.bat file is only created in an iocBoot subdirectory, I don’t think it’s going to be the solution here. If these tests start the IOC from a Perl script you should be able to adjust $ENV{PATH} in Perl beforehand (on Windows targets) to include your own $(TOP)/lib/$(ARCH) directory.

HTH,

- Andrew

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System