Re: epics build system question again - build order

["Johnson, Andrew N. via Tech-talk" <tech-talk@aps.anl.gov>]

IIRC STATIC_BUILD=YES/NO controls whether the linker should make use of lib*.so files when generating executables, but I don't remember if it affects generating libraries. I'm not sure now which solution William needs, but one or the other should work.

 

There are also ways to pass sets of flags and lists of libraries from one module to another, so you don't have to explicitly add them to the downstream app. You put those flags into one or more variables in a CONFIG_module_MODULE file which the upstream module publishes in its $TOP/cfg directory, then the downstream module uses those variables. That file will be included automatically in all downstream builds where the RELEASE file points to that module. The built-in pvData and pvAccess modules which are part of Base use that technique.

 

- Andrew

 

On 6/10/24, 2:25 PM, "Tech-talk" <tech-talk-bounces@aps.anl.gov> wrote:

 

Hi William,

 

·         another quick question: how can I tell EPICS to static compile the support library?

·         It uses some system library that needs additional compiler flags, and I would have to repeat them in the IOC-generating App... 

Put this line in the support Makefile:

 

STATIC_BUILD=YES

 

However, that may not do what you want.  On most modern Linux systems the system libraries are only available as shareable libraries (.so), they are no longer provided as static libraries (.a).  That means the IOC-generating App does need to build with the system libraries, they won’t be included in the statically built support library.

 

Mark

 

 

From: Tech-talk <tech-talk-bounces@aps.anl.gov> On Behalf Of William Kirstaedter via Tech-talk
Sent: Monday, June 10, 2024 1:19 PM
To: Ralph Lange <ralph.lange@gmx.de>; EPICS Tech Talk <tech-talk@aps.anl.gov>
Subject: Re: epics build system question again - build order

 

Thanks.

Its a support library as far as I can tell.
source: https://groups.nscl.msu.edu/controls/files/devSnmp.html
download: https://groups.nscl.msu.edu/controls/

I think renaming to snmpSup is more self-explanatory, that way the Makefile stays default ... nobody reads Makefiles, or check for irregularities. :>

another quick question: how can I tell EPICS to static compile the support library?
It uses some system library that needs additional compiler flags, and I would have to repeat them in the IOC-generating App... 

cheers!

William Kirstaedter

PP&B Computer Support Group

Fritz-Haber-Institut Berlin

Am 10.06.24 um 19:57 schrieb Ralph Lange via Tech-talk:

On Mon, 10 Jun 2024 at 19:47, William Kirstaedter via Tech-talk <tech-talk@aps.anl.gov> wrote:

my main App is called IOCINFRAApp, the support App is called snmpApp.
the build system now tries to compile IOCINFRAApp first, and fails
because a dbd file from snmpApp is not yet available.

I've renamed my snmpApp to 0snmpApp and it works, but thats too hacky in
my eyes.
Is there some more elegant way to achieve that snmpApp gets built before
IOCINFRAApp ?

 

In general:

There are applications that generate IOCs, and there are support applications that provide things (libraries, templates) to be used by IOC-creating apps.

If the IOC-creating kind are called *App and the support applications are called *Sup, the default order (first *Sup, then *App) will work.

 

Specifically:

You can always declare a dependency that is not covered by the default build order in the Makefile. In your case,

IOCINFRAApp_DEPEND_DIRS += snmpApp

 

Cheers,
~Ralph