RE: cross-compiling Base 7.0.6 for win32

["Daykin, Evan via Tech-talk" <tech-talk at aps.anl.gov>]

Ah, I didn’t even notice that last OP_SYS_LDLIBS line! You’re a hero! Removing all but the SHARED_LIBRARIES/STATIC_BUILD lines seems to fix everything.  I’ll keep the static build since I’m ultimately creating a debian package out of this.

 

Cheers,

Evan

 

 

From: Freddie Akeroyd - STFC UKRI <freddie.akeroyd at stfc.ac.uk>
Sent: Monday, March 28, 2022 6:30 PM
To: Daykin, Evan <daykin at frib.msu.edu>; tech-talk at aps.anl.gov
Subject: RE: cross-compiling Base 7.0.6 for win32

 

[EXTERNAL] This email originated from outside of FRIB

Hi Evan,

 

So it looks like the patch re-defines OP_SYS_LDLIBS which is what has probably caused your build issues. This addition may have been required to make things work for a static build at some point in the past? A static build will make the executables self contained and thus easier to distribute, maybe also at some previous time DLL builds in MinGW didn’t quite work as well as static ones, but I’m guessing as I don’t know and history of this. There is also the issue of symbol hiding, with a windows DLL only functions explicitly marked as “for export” are available for use from a library by other programs, whereas if you build a static library all functions are visible to IOCs linked against them, so there may also have been some history of library symbol/function visibility. It may be safer to keep your build static for backward compatibility reasons if other programs link against the libraries you build.

 

On ununtu I only needed

 

SHARED_LIBRARIES=NO

STATIC_BUILD=YES

 

It might be you can now also remove all the patch changes apart from these lines

 

Regards,

 

Freddie      

 

From: Daykin, Evan <daykin at frib.msu.edu>
Sent: 28 March 2022 21:08
To: Akeroyd, Freddie (STFC,RAL,ISIS) <freddie.akeroyd at stfc.ac.uk>; tech-talk at aps.anl.gov
Subject: RE: cross-compiling Base 7.0.6 for win32

 

Good point, I see that on my end as well.  And now that you mention it, I will look through our site-specific patch files to see if this is getting screwed up somewhere/

 

STATIC_BUILD is being set in configure/os/CONFIG_SITE.Common.win32-x86-mingw, as part of a patch that pre-dates my time here:

 

Date: Tue, 29 Dec 2015 11:41:22 -0800

Subject: Cross-build with mingw32

 

---

configure/os/CONFIG_SITE.Common.win32-x86-mingw    | 15 +++++++++++++++

configure/os/CONFIG_SITE.linux-x86.win32-x86-mingw |  4 ++--

2 files changed, 17 insertions(+), 2 deletions(-)

 

diff --git a/configure/os/CONFIG_SITE.Common.win32-x86-mingw b/configure/os/CONFIG_SITE.Common.win32-x86-mingw

index ba19ac6..d2f74bb 100644

--- a/configure/os/CONFIG_SITE.Common.win32-x86-mingw

+++ b/configure/os/CONFIG_SITE.Common.win32-x86-mingw

@@ -5,3 +5,18 @@

# If readline is available uncomment the following line

# to enable command-line editing and history support

#COMMANDLINE_LIBRARY = READLINE

+

+CMPLR_PREFIX=i686-w64-mingw32-

+

+SHARED_LIBRARIES=NO

+STATIC_BUILD=YES

+

+# No -fPIC avoids "-fPIC ignored for target (all code is position independent)"

+SHRLIB_CFLAGS =

+SHRLIB_LDFLAGS = -shared -Wl,--out-implib,$(LIB_PREFIX)$*$(LIB_SUFFIX)

+LOADABLE_SHRLIB_LDFLAGS = -shared -Wl,--out-implib,$(LIB_PREFIX)$*$(LIB_SUFFIX)

+

+# Override linking with gcc library from CONFIG.gnuCommon

+GNU_LDLIBS_YES =

+

+OP_SYS_LDLIBS = -lws2_32

diff --git a/configure/os/CONFIG_SITE.linux-x86.win32-x86-mingw b/configure/os/CONFIG_SITE.linux-x86.win32-x86-mingw

index dfc947e..cad5db1 100644

--- a/configure/os/CONFIG_SITE.linux-x86.win32-x86-mingw

+++ b/configure/os/CONFIG_SITE.linux-x86.win32-x86-mingw

@@ -15,9 +15,9 @@

 

 # Different distribution cross-build packages use different prefixes:

# Ubuntu:

-#CMPLR_PREFIX = i686-w64-mingw32-

+CMPLR_PREFIX = i686-w64-mingw32-

# RHEL:

-CMPLR_PREFIX = i686-pc-mingw32-

+#CMPLR_PREFIX = i686-pc-mingw32-

# Debian?

#CMPLR_PREFIX = i586-mingw32msvc-

 

I am not exactly sure why static build is necessary; there is no commentary along with the patch. Do you know of any reason why this would be required?

 

 

From: Freddie Akeroyd - STFC UKRI <freddie.akeroyd at stfc.ac.uk>
Sent: Monday, March 28, 2022 3:59 PM
To: Daykin, Evan <daykin at frib.msu.edu>; tech-talk at aps.anl.gov
Subject: RE: cross-compiling Base 7.0.6 for win32

 

[EXTERNAL] This email originated from outside of FRIB

Hi Evan,

 

I’ve now tried a mingw build on Ubuntu 20.04 and found I didn’t need to make any changes, the  dbghelp  and psapi libraries are already listed in the  OP_SYS_LDLIBS  for mingw and this got automatically added to my link line when building tests and other things, but from the link line in your post this doesn’t seem to be happening. Which epics config file did you specify STATIC_BUILD in? I added this to CONFIG_SITE along with CROSS_COMPILER_TARGET_ARCHS and that all seemed to work for me with no additional libraries.

 

Regards,

 

Freddie    

 

From: Daykin, Evan <daykin at frib.msu.edu>
Sent: 28 March 2022 20:37
To: Akeroyd, Freddie (STFC,RAL,ISIS) <freddie.akeroyd at stfc.ac.uk>; tech-talk at aps.anl.gov
Subject: RE: cross-compiling Base 7.0.6 for win32

 

Hi Freddie,

 

Yes, this fixed the initial problem. I also needed to add ‘psapi’ here and in modules/ca/src/client/Makefile. Thank you for your help! Almost done with a 7.0.6 Debian package now.

 

-Evan

 

From: Freddie Akeroyd - STFC UKRI <freddie.akeroyd at stfc.ac.uk>
Sent: Friday, March 25, 2022 8:05 PM
To: Daykin, Evan <daykin at frib.msu.edu>; tech-talk at aps.anl.gov
Subject: RE: cross-compiling Base 7.0.6 for win32

 

[EXTERNAL] This email originated from outside of FRIB

Hi Evan,

 

These functions are part of the “dbghelp” library that looks to be missing from your link line. I suspect that this library is needed in this case because it is a static build, for a shared (DLL) build it would have been linked into COM I expect. If you edit

 

    modules/libcom/test/Makefile

 

and change the PROD_SYS_LIBS_WIN32 line to be

 

PROD_SYS_LIBS_WIN32 += ws2_32 advapi32 user32 dbghelp    

 

Does that help?

 

Freddie

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Daykin, Evan via Tech-talk
Sent: 24 March 2022 18:55
To: EPICS tech-talk <tech-talk at aps.anl.gov>
Subject: cross-compiling Base 7.0.6 for win32

 

Hi Tech Talk,

 

I am attempting to build Base version 7.0.6, with “CROSS_COMPILER_TARGET_ARCHS=linux-x86_64-debug win32-x86-mingw” on Debian 11, kernel version 5.10.0-8-amd64. I am getting the following error:

 

/usr/bin/i686-w64-mingw32-g++ -o epicsTypesTest.exe -static -L/user/daykin/git/epics-base/lib/win32-x86-mingw       -m32   -static-libgcc -static-libstdc++         epicsTypesTest.o    -lCom  -lws2_32 -ladvapi32 -luser32    -lws2_32

/usr/bin/i686-w64-mingw32-ld: /user/daykin/git/epics-base/lib/win32-x86-mingw/Com.lib(osdFindAddr.o):osdFindAddr.c:(.text+0x7b): undefined reference to `_imp__SymFromAddr@20'

/usr/bin/i686-w64-mingw32-ld: /user/daykin/git/epics-base/lib/win32-x86-mingw/Com.lib(osdFindAddr.o):osdFindAddr.c:(.text+0xf1): undefined reference to `_imp__SymSetOptions@4'

/usr/bin/i686-w64-mingw32-ld: /user/daykin/git/epics-base/lib/win32-x86-mingw/Com.lib(osdFindAddr.o):osdFindAddr.c:(.text+0x118): undefined reference to `_imp__SymInitialize@12'

/usr/bin/i686-w64-mingw32-ld: /user/daykin/git/epics-base/lib/win32-x86-mingw/Com.lib(osdFindAddr.o):osdFindAddr.c:(.text+0x1bd): undefined reference to `_imp__SymGetLineFromAddr64@20'

collect2: error: ld returned 1 exit status

 

I suppose this has something to do with the win32 API, but I’m not sure what I’m doing wrong; I have every gcc-mingw* package installed.  Has anyone experienced this before?

 

Evan Daykin Controls Engineer Facility for Rare Isotope Beams Michigan State University 640 South Shaw Lane East Lansing, MI 48824, USA Tel. 517-908-7678 Email: daykin at frib.msu.edu

 

 

This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses.