RE: LIB_LIBS getting ignored

["Jones, Edward \(CODAS&IT\) via Tech-talk" <tech-talk at aps.anl.gov>]

Hi Mark,

We do, to explain our setup a bit more clearly. We're using this repo of ADPICam (however the issue would be seen with the original repo and probably a lot of AreaDetector modules): https://github.com/mfurseman/ADPICam/tree/deploy

The setup is using linux as the host arch so we can build on a linux docker in Gitlab - company only provides docker based, there are some windows runners/dockers however those are all broken as Microsoft badly maintain them and this requires licenses. We're very adverse to licenses as they're hard to acquire - while we do have Microsoft and Visual Studio licenses we wanted to keep this open to all our users without needing to worry about this. On a similar note, we decided on cross compiling with MinGW rather than Visual Studio Build Tools (although people tell me I could use it anyway). As a result of this I have the fork and pull request to fix ADSupport for statically building with MinGW:

https://github.com/sudilav/ADSupport
https://github.com/areaDetector/ADSupport/pull/36
https://github.com/areaDetector/ADSupport/pull/35

As a result we also have to keep a internal copy of areaDetector as it points to this "newer" version of areaDetector for now. It'd be nice if someone could review my pull request 😊 and then subsequently repoint areaDetector to the newer version of ADSupport afterwards. Anyway, the final difference is this:

We use INSTALL_LOCATION and point all of base, modules and areaDetector (except ADPICam - our IOC), to one folder (let's call it /prefix). This is to reduce the overall download size on our deployment machines - 2-10GB became 450MB so we liked this part of the build facility.

As a result of this final stage, our RELEASE.local pointed EPICS_BASE and SUPPORT both to /prefix. It turns out we can build without a RELEASE.local though, we do only need to run make with them set in the command itself. The actual issue and probably something which needs fixing:

Within both an App and IOC's src Makefile it points to include $(ADCORE)/ADApp/commonLibraryMakefile. When you use INSTALL_LOCATION this is actually: $(INSTALL_LOCATION)/cfg/commonLibraryMakefile so I had to rewrite this line in the App, for the IOC this is very similar but for commonDriverMakefile. My issue was that I copied and pasted at this point and put the include to the commonLibraryMakefile in the IOC Makefile, once I realised my mistake and rewrote it for commonDriverMakefile my build started working again.

https://github.com/areaDetector/ADPICam/blob/9836d85828964c12c58dc4ae5d4b7c1e436def57/PICamApp/src/Makefile#L16
https://github.com/areaDetector/ADPICam/blob/9836d85828964c12c58dc4ae5d4b7c1e436def57/iocs/PICamIOC/PICamApp/src/Makefile#L20

Since ADApp is hardcoded after ADCORE we couldn't simply set ADCORE and required an actual change to the code. Maybe there could be a way of supporting users who are using INSTALL_LOCATION? It's a very useful feature and hopefully all the above appears as a logical setup that someone would want. INSTALL_LOCATION appeared to be the most challenging to understand - would be nice if there's more documentation on how that actually works when it comes to dependencies in the build.

Anyway, for now we can now build our Gitlab pipeline all the way to our IOC and deploy so that's happily working.

Thanks for your assistance, apologies it turns out to be a typo but thought I'd provide a concise explanation of our setup in case anyone else uses INSTALL_LOCATION in this manner for areaDetector so they might find this useful.

Ed

-----Original Message-----
From: Mark Rivers <rivers at cars.uchicago.edu> 
Sent: 27 August 2021 00:14
To: Jones, Edward (CODAS&IT) <edward.jones1 at ukaea.uk>
Cc: Johnson, Andrew N. <anj at anl.gov>; EPICS tech-talk <tech-talk at aps.anl.gov>
Subject: Re: LIB_LIBS getting ignored

Do you also have a RELEASE file in addition to RELEASE.local? I believe you need that. You can use makeBaseApp.pl to construct the RELEASE file.

If that does not fix it then please send the complete output when you run make.

Mark

Sent from my iPhone

On Aug 26, 2021, at 12:03 PM, Jones, Edward (CODAS&IT) via Tech-talk <tech-talk at aps.anl.gov> wrote:


Hi Andrew,

Unfortunately adding a RELEASE.local into configure has not worked for my ioc. I still receive the same error, I’ve set the Makefile to print several variables to verify what might be going wrong. EPICS_BASE_IOC_LIBS correctly prints that it contains:

dbRecStd dbCore ca Com

The Makefile does include the commonDriverMakefile from ADApp and successfully finds it where EPICS_BASE_IOC_LIBS is added as well as asyn:

https://github.com/areaDetector/ADCore/blob/19bb3bfa1c1b11caa0da11a2cf4a1b375f724f52/ADApp/commonDriverMakefile

In my RELEASE.local file I only define EPICS_BASE and SUPPORT, is there anything else needed?

Thanks,

Ed

From: Johnson, Andrew N. <anj at anl.gov>
Sent: 24 August 2021 18:13
To: Jones, Edward (CODAS&IT) <edward.jones1 at ukaea.uk>
Cc: EPICS tech-talk <tech-talk at aps.anl.gov>
Subject: Re: LIB_LIBS getting ignored

Hi Ed,

On Aug 24, 2021, at 7:24 AM, Jones, Edward (CODAS&IT) via Tech-talk <tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>> wrote:

I’m trying to run a build where we’ve set INSTALL_LOCATION to /prefix and have found a buildable form with:

make EPICS_BASE=/prefix SUPPORT=/prefix

Your setting EPICS_BASE (and possibly SUPPORT too) on the make command-line is likely to be (at least part of) the reason for your issue. You really do have to set all paths in a configure/RELEASE file or in a RELEASE.local file that gets included from that because the build system has Perl scripts which read the RELEASE files independently of GNUmake and use the results to provide things to the build system like the list of paths to be searched for header and library files. I haven’t looked at the build in detail to see why you might be getting that problem, but please start by adding EPICS_BASE and SUPPORT to your RELEASE file chain and report back to tech-talk if that doesn’t (help you) solve it.



However, when I try to build my IOC itself at the final hurdle it doesn’t seem to link anything. This is what it tries to link:

/usr/bin/x86_64-w64-mingw32-g++ -o PICamApp.exe -static -L/ADPICam/lib/windows-x64-mingw -L/ADPICam/iocs/PICamIOC/lib/windows-x64-mingw       -m64    -static-libgcc -static-libstdc++         PICamApp_registerRecordDeviceDriver.o PICamAppMain.o    -lADPICam -lPicam  -lnetapi32    -lpsapi -lws2_32 -ladvapi32 -luser32 -lkernel32 -lwinmm -ldbghelp

Which lacks all the EPICS_BASE_IOC_LIBS, when I manually navigate to that directory and link it like so:

/usr/bin/x86_64-w64-mingw32-g++ -o PICamApp.exe -static -L/ADPICam/lib/windows-x64-mingw -L/ADPICam/iocs/PICamIOC/lib/windows-x64-mingw -L/prefix/lib/windows-x64-mingw      -m64    -static-libgcc -static-libstdc++         PICamApp_registerRecordDeviceDriver.o PICamAppMain.o    -lADPICam -lPicam  -lnetapi32    -lpsapi -lws2_32 -ladvapi32 -luser32 -lkernel32 -lwinmm -ldbghelp -ldbRecStd -ldbCore -lca -lCom -lasyn -lADBase -lca -lCom -lxml2 -lgdi32 -loleaut32 -lwsock32 -lws2_32 -lpsapi -ldbghelp -lversion -lzlib -lpv -ladvapi32 -luser32

This works. So it looks like the build method is missing all LIB_LIBS definitions. Could someone help to understand this? If you need I can share our work but must be privately done.

I’m the lead maintainer for the build system but I don’t have time to look into any details this week. I’m pretty sure the above should solve it, but if not you might also get some input from others too as long as you respond back to the list and not just to me privately. It often helps to post parts of your Makefiles if they’re your own or you have made changes to them, or pointers to online copies if they are unmodified from published support modules. We shouldn’t have to see any private code to help fix this.

- Andrew

--
Complexity comes for free, simplicity you have to work for.