Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Thu, 28 Feb 2013 00:43:28 +0000

Thanks, I should have compared the new CONFIG_SITE files to my old ones.

I don't know how to make that process better, but copying and reconciling the CONFIG_SITE files between EPICS releases is one of the most tedious and error prone parts of upgrading EPICS base.

Mark

-----Original Message-----
From: Andrew Johnson [mailto:[email protected]] 
Sent: Wednesday, February 27, 2013 4:33 PM
To: Mark Rivers
Cc: 'Janet Anderson'; [email protected]
Subject: Re: Problem building EPICS 3.14.12.3 on Cygwin

Hi Mark,

On 2013-02-27 Mark Rivers wrote:
> The problem appears to be that CONFIG.Common.cygwin-x86 has changed:

The CONFIG_SITE.Common.cygwin-x86 file also changed.  If you read the comments 
in the latest file it gives an alternative LDLIBS_READLINE setting to use if 
your build fails due to readline.  We do occasionally move configuration 
settings around between releases, so you shouldn't assume that you can just 
copy your old CONFIG_SITE files over when installing a new release.  We 
probably should have mentioned this particular change in the release notes 
though, for which omission I apologize.

> Note that in 3.14.12.3 LDLIBS_READLINE is missing "-lcurses".  If I
>  manually add -lcurses back into that file the build succeeds.
> 
> My Cygwin libreadline installation is "libreadline7 6.1.2-3", which I
>  believe is the most recent.

> Is there a reason that -lcurses was removed from CONFIG.Common.cycwin-x86?

We try to configure Base so by default it does not link against libraries 
unnecessarily, but we do explain in the CONFIG_SITE files what you might need 
to change if the build fails.  We thus made the default to *not* link against 
readline on Cygwin; you now have to explicitly configure that in if you want 
it.

My Cygwin also has readline 6.1.2-3 but the "cygreadline7.dll" that gets 
linked in doesn't need to be explicitly linked with curses — it automatically 
pulls in "cygncursesw-10.dll" without having to be told to do so:

$ ldd bin/cygwin-x86/softIoc.exe
        ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x76fa0000)
        kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x74c70000)
        KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll 
(0x76520000)
        asIoc.dll => /cygdrive/d/epics/mirror-3.14/bin/cygwin-x86/asIoc.dll 
(0x6c080000)
        ca.dll => /cygdrive/d/epics/mirror-3.14/bin/cygwin-x86/ca.dll 
(0x6e500000)
        Com.dll => /cygdrive/d/epics/mirror-3.14/bin/cygwin-x86/Com.dll 
(0x70780000)
        cygwin1.dll => /usr/bin/cygwin1.dll (0x61000000)
        cygreadline7.dll => /usr/bin/cygreadline7.dll (0x6d5f0000)
        cygncursesw-10.dll => /usr/bin/cygncursesw-10.dll (0x6dc40000)
        cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x6e600000)
etc.

I see that you built a static binary, whereas I'm using shared libraries.  
That explains the difference, a static library (.a file) can't tell the linker 
what other libraries need to be pulled in, whereas a .dll can.  Since the 
latest DLL gets linked against libncursesw rather than libcurses, that implies 
we should probably be using
	LDLIBS_READLINE = -lreadline -lncursesw
which works for me with a static build and won't pull in any extraneous DLLs.  
I don't know if that will break on older versions of Cygwin though.

- Andrew
-- 
There is no such thing as a free lunch.  When invited for lunch,
it is best to check if you are there to eat, or to be eaten.
-- Clive Robinson

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System