Experimental Physics and
Industrial Control System

Also if you were looking for a static netsnmp that could be added to an epics build tree, you may be able to use https://github.com/ISISComputingGroup/NET-SNMP

 

Regards,

 

Freddie

 

 

Hi,

 

I’d made a few changes to devSnmp for WIN32 compilation which I hadn’t got round to feeding back upstream. Looking back at the differences, it seems there is a hard coded SHARED_LIBRARIES=YES / STATIC_BUILD=NO in configure/CONFIG_APP for the devSnmp module that I removed in our fork so we could build statically on windows

 

Regards,

 

Freddie

 

 

 

ahh Freddie has a modified version https://github.com/ISISComputingGroup/EPICS-devSnmp

well, too late :>

William Kirstaedter

PP&B Computer Support Group

Fritz-Haber-Institut Berlin

Thank you guys for the quick answers.

as you promised, my netsnmp library only exists as a shared one, so the build still fails with stuff like

/usr/bin/ld: /home/epics/FHI/IOCINFRA/lib/linux-x86_64/libdevSnmp.so: undefined reference to `usmAESPrivProtocol'

I guess then I dont get around doubling the compiler flag lines.

cheers,

William Kirstaedter

PP&B Computer Support Group

Fritz-Haber-Institut Berlin

Am 10.06.24 um 20:37 schrieb Mark Rivers:

Sorry, Andrew is right, to build the support library statically only use SHARED_LIBRARIES=NO.

 

STATIC_BUILD=YES would be used in the IOC application Makefile to tell it to link with static support libraries, so the executable does not depend on any EPICS shareable libraries.

 

Mark

 

 

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

 

Hi William,

 

If you edit the Makefile which creates the library and set SHARED_LIBRARIES=NO that will tell the build system to not generate any lib*.so files when building that library. The IOC-generating app will still need to link with the shared libraries from upstream (snmp etc.), but it sounds like that would work for you.

 

- Andrew

 

 

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

 

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 at 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