Experimental Physics and
Industrial Control System

"Hill, Jeff" <[email protected]> · Tue, 19 Nov 2013 23:52:52 +0000

I see now that this one is recommended.

http://gnuwin32.sourceforge.net/packages/make.htm

> -----Original Message-----
> From: Hill, Jeff
> Sent: Tuesday, November 19, 2013 4:49 PM
> To: Hill, Jeff; Andrew Johnson
> Cc: [email protected]
> Subject: RE: undefined symbols in windows build
> 
> PS: The permutations documented in the previous MM were building for
> win32-x86-mingw. I can observe also that permutation 8 works perfectly for
> win32-x86. I didn't benefit from the experience of attempting all of the other
> permutations for win32-x86, but I know that at least some of them don`t
> work.
> 
> A similar comment applies.
> 
> The win32-x86 target builds, but the currently supplied gnu make in mingw
> doesn't seem to work unless I add "SHELL = cmd.exe" to CONFIG.win32-
> x86.Common. I can't say for certain if this is ending up with a strange hybrid
> of mingw32-make 3.82 and msys make.exe 3.81, but msys _must_ be in the
> path when it works so we can make some guesses.
> 
> Is there an EPICS approved/recommended source for installing gnu make 3.81
> on windows?
> 
> Jeff
> 
> > -----Original Message-----
> > From: [email protected] [mailto:core-talk-
> > [email protected]] On Behalf Of Hill, Jeff
> > Sent: Tuesday, November 19, 2013 4:17 PM
> > To: Andrew Johnson
> > Cc: [email protected]
> > Subject: RE: undefined symbols in windows build
> >
> > Hi Andrew,
> >
> > It does appear that this is caused by another gnu make issue on windows.
> >
> > When this type of problem happens one must search for the exact
> > permutation that works. So maybe it's worthwhile to document some
> > observations related to what works, and how one goes about locating a
> > permutation that does so that maybe we can avoid expending time on this
> > particular issue in the future.
> >
> > My currently installed make is mingw32-make.exe, and it`s at version 3.82.
> It's
> > probably the only version that mingw currently provides. There is also
> > another version of make in msys make.exe which is at 3.81.
> >
> > permutation 0
> > o mingw32-make 3.82, SHELL variable not defined, msys not in the path.
> > => iocLogServer undefined symbols
> >
> > permutation 1
> > o mingw32-make 3.82, SHELL variable defined to be cmd.exe in the setup
> > script, msys not in the path.
> > => iocLogServer undefined symbols
> >
> > permutation 2
> > o mingw32-make 3.82, SHELL variable defined to be cmd.exe in
> > CONFIG.win32-x86-mingw.Common, msys not in the path.
> > => iocLogServer undefined symbols
> >
> > permutation 3
> > o msys make 3.81, SHELL variable not defined, msys in the path.
> > => problems like this
> > ..\\..\\..\\bin\\win32-x86-mingw\\antelope.exe -bparse -l -d
> > ../../../src/libCom/flex/parse.y
> > make[3]: ..\..\..\bin\win32-x86-mingw\antelope.exe: Command not found
> >
> > permutation 4
> > o mingw32-make 3.82, SHELL variable not defined, msys in the path.
> > => problems like this
> > ..\\..\\..\\bin\\win32-x86-mingw\\e_flex.exe -S../../../include/flex.skel.static
> -8
> > -I -t ../../../src/libCom/as/asLib_lex.l > asLib_lex.yy.c
> > /usr/bin/sh: ......binwin32-x86-mingwe_flex.exe: command not found
> >
> > permutation 5
> > o msys make 3.81, SHELL variable defined to be cmd.exe in the setup script,
> > msys in the path.
> > => problems like this
> > ..\\..\\..\\bin\\win32-x86-mingw\\antelope.exe -bparse -l -d
> > ../../../src/libCom/flex/parse.y
> > make[3]: ..\..\..\bin\win32-x86-mingw\antelope.exe: Command not found
> >
> > permutation 6
> > o mingw32-make 3.82, SHELL variable defined to be cmd.exe in the setup
> > script, msys in the path.
> > => problems like this
> > ..\\..\\..\\bin\\win32-x86-mingw\\e_flex.exe -S../../../include/flex.skel.static
> -8
> > -I -t ../../../src/libCom/as/asLib_lex.l > asLib_lex.yy.c
> > /usr/bin/sh: ......binwin32-x86-mingwe_flex.exe: command not found
> >
> > permutation 7
> > o msys make 3.81, SHELL variable defined to be cmd.exe in CONFIG.win32-
> > x86-mingw.Common, msys in the path.
> > => problems like this
> > ..\\..\\..\\bin\\win32-x86-mingw\\antelope.exe -bparse -l -d
> > ../../../src/libCom/flex/parse.y
> > make[3]: ..\..\..\bin\win32-x86-mingw\antelope.exe: Command not found
> > C:\hill\epicsInBazaar\epicsR3.15-unmodified\trunk>make clean
> > make -C ./configure clean
> > 'onfigure' is not recognized as an internal or external command,
> > operable program or batch file.
> >
> > permutation 8
> > o  minge32-make 3.82, SHELL variable defined to be cmd.exe in
> > CONFIG.win32-x86-mingw.Common, msys in the path.
> > => success !
> >
> > So it builds, but it takes some effort to find a permutation that does, and the
> > currently supplied gnu make in mingw doesn't seem to work unless I add "
> > SHELL = cmd.exe" to CONFIG.win32-x86-mingw.Common. I can't say for
> > certain if this is ending up with a strange hybrid of mingw32-make 3.82 and
> > msys make.exe 3.81 since msys _is_ in the path when it works. The problem
> > with dropping back to mingw32-make 3.81 is actually finding one to use
> since
> > mingw is supplying now only 3.82?
> >
> > Here is also an interesting paragraph provided by the "mingw-get list
> > mingw32-make" command.
> >
> > >mingw-get list mingw32-make
> >
> > Package: mingw32-make                                 Subsystem: mingw32
> > Components: bin, doc, lang, lic
> >
> > GNU make utility to maintain groups of programs
> > -----------------------------------------------
> >
> > The `make' utility automatically determines  which  pieces  of  a  large
> > program  need  to  be recompiled, and issues commands to recompile them.
> > GNU `make' was implemented  by  Richard  Stallman  and  Roland  McGrath.
> > Development since Version 3.76 has been handled by Paul D. Smith.
> >
> > The MinGW/MSYS project provides two  versions  of  make:  the  msys-
> make
> > version  acts  generally  more as make is intended to operate, and gives
> > fewer headaches during execution. However, msys-make requires  the
> MSYS
> > dll.  This  version,  mingw32-make,  does  not require the MSYS dll, but
> > because of the lack of POSIX support in "pure" Win32  has  a  number  of
> > known shortcomings in comparison.
> >
> > Here is also the paragraphs in the gnu make manual on choosing the shell.
> >
> > 5.3.2 Choosing the Shell
> >
> > The program used as the shell is taken from the variable SHELL. If this
> variable
> > is not set in your makefile, the program /bin/sh is used as the shell. The
> > argument(s) passed to the shell are taken from the variable .SHELLFLAGS.
> The
> > default value of .SHELLFLAGS is -c normally, or -ec in POSIX-conforming
> mode.
> >
> > Unlike most variables, the variable SHELL is never set from the environment.
> > This is because the SHELL environment variable is used to specify your
> > personal choice of shell program for interactive use. It would be very bad
> for
> > personal choices like this to affect the functioning of makefiles. See
> Variables
> > from the Environment.
> >
> > Furthermore, when you do set SHELL in your makefile that value is not
> > exported in the environment to recipe lines that make invokes. Instead, the
> > value inherited from the user's environment, if any, is exported. You can
> > override this behavior by explicitly exporting SHELL (see Communicating
> > Variables to a Sub-make), forcing it to be passed in the environment to
> recipe
> > lines.
> >
> > However, on MS-DOS and MS-Windows the value of SHELL in the
> > environment is used, since on those systems most users do not set this
> > variable, and therefore it is most likely set specifically to be used by make.
> On
> > MS-DOS, if the setting of SHELL is not suitable for make, you can set the
> > variable MAKESHELL to the shell that make should use; if set it will be used
> as
> > the shell instead of the value of SHELL.
> > Choosing a Shell in DOS and Windows
> >
> > Choosing a shell in MS-DOS and MS-Windows is much more complex than
> on
> > other systems.
> >
> > On MS-DOS, if SHELL is not set, the value of the variable COMSPEC (which is
> > always set) is used instead.
> >
> > The processing of lines that set the variable SHELL in Makefiles is different
> on
> > MS-DOS. The stock shell, command.com, is ridiculously limited in its
> > functionality and many users of make tend to install a replacement shell.
> > Therefore, on MS-DOS, make examines the value of SHELL, and changes its
> > behavior based on whether it points to a Unix-style or DOS-style shell. This
> > allows reasonable functionality even if SHELL points to command.com.
> >
> > If SHELL points to a Unix-style shell, make on MS-DOS additionally checks
> > whether that shell can indeed be found; if not, it ignores the line that sets
> > SHELL. In MS-DOS, GNU make searches for the shell in the following places:
> >
> >     In the precise place pointed to by the value of SHELL. For example, if the
> > makefile specifies 'SHELL = /bin/sh', make will look in the directory /bin on
> the
> > current drive.
> >     In the current directory.
> >     In each of the directories in the PATH variable, in order.
> >
> > In every directory it examines, make will first look for the specific file (sh in
> > the example above). If this is not found, it will also look in that directory for
> > that file with one of the known extensions which identify executable files.
> For
> > example .exe, .com, .bat, .btm, .sh, and some others.
> >
> > If any of these attempts is successful, the value of SHELL will be set to the
> full
> > pathname of the shell as found. However, if none of these is found, the
> value
> > of SHELL will not be changed, and thus the line that sets it will be effectively
> > ignored. This is so make will only support features specific to a Unix-style
> shell
> > if such a shell is actually installed on the system where make runs.
> >
> > Note that this extended search for the shell is limited to the cases where
> > SHELL is set from the Makefile; if it is set in the environment or command
> > line, you are expected to set it to the full pathname of the shell, exactly as
> > things are on Unix.
> >
> > The effect of the above DOS-specific processing is that a Makefile that
> > contains 'SHELL = /bin/sh' (as many Unix makefiles do), will work on MS-
> DOS
> > unaltered if you have e.g. sh.exe installed in some directory along your
> PATH.
> >
> > Jeff
> >
> > > -----Original Message-----
> > > From: Andrew Johnson [mailto:[email protected]]
> > > Sent: Tuesday, November 19, 2013 1:17 PM
> > > To: [email protected]; Hill, Jeff
> > > Subject: Re: undefined symbols in windows build
> > >
> > > Hi Jeff,
> > >
> > > On 11/19/2013 01:11 PM, Hill, Jeff wrote:
> > > >
> > > > FWIW, I see some undefined symbols early in the build when building
> > R3.15
> > > native for windows with both mingw and also MS compilers. See below.
> > > >
> > > > C:\hill\epicsInBazaar\epicsR3.15-atomics-small-
> > > fixes\trunk\src\libCom\O.win32-x86-
> > > mingw/../../../src/libCom/log/iocLogServer.c:102: undefined reference to
> > > `_imp__epicsGetStderr@0'
> > > > C:\hill\epicsInBazaar\epicsR3.15-atomics-small-
> > > fixes\trunk\src\libCom\O.win32-x86-
> > > mingw/../../../src/libCom/log/iocLogServer.c:103: undefined reference to
> > > `_imp__epicsGetStderr@0'
> > > > C:\hill\epicsInBazaar\epicsR3.15-atomics-small-
> > > fixes\trunk\src\libCom\O.win32-x86-
> > > mingw/../../../src/libCom/log/iocLogServer.c:110: undefined reference to
> > > `_imp__epicsGetStderr@0'
> > > > C:\hill\epicsInBazaar\epicsR3.15-atomics-small-
> > > fixes\trunk\src\libCom\O.win32-x86-
> > > mingw/../../../src/libCom/log/iocLogServer.c:114: undefined reference to
> > > `_imp__fdmgr_init@0'
> > > > C:\hill\epicsInBazaar\epicsR3.15-atomics-small-
> > > fixes\trunk\src\libCom\O.win32-x86-
> > > mingw/../../../src/libCom/log/iocLogServer.c:116: undefined reference to
> > > `_imp__epicsGetStderr@0'
> > > > C:\hill\epicsInBazaar\epicsR3.15-atomics-small-
> > > fixes\trunk\src\libCom\O.win32-x86-
> > > mingw/../../../src/libCom/log/iocLogServer.c:124: undefined reference to
> > > `_imp__epicsSocketCreate@12'
> > > > C:\hill\epicsInBazaar\epicsR3.15-atomics-small-
> > > fixes\trunk\src\libCom\O.win32-x86-
> > > mingw/../../../src/libCom/log/iocLogServer.c:127: undefined reference to
> > > `_imp__epicsSocketConvertErrnoToString'
> > > > C:\hill\epicsInBazaar\epicsR3.15-atomics-small-
> > > fixes\trunk\src\libCom\O.win32-x86-
> > > mingw/../../../src/libCom/log/iocLogServer.c:128: undefined reference to
> > > `_imp__epicsGetStderr@0'
> > > > C:\hill\epicsInBazaar\epicsR3.15-atomics-small-
> > > fixes\trunk\src\libCom\O.win32-x86-
> > > mingw/../../../src/libCom/log/iocLogServer.c:132: undefined reference to
> > > `_imp__epicsSocketEnableAddressReuseDuringTimeWait
> > > > C:\hill\epicsInBazaar\epicsR3.15-atomics-small-
> > > fixes\trunk\src\libCom\O.win32-x86-
> > > mingw/../../../src/libCom/log/iocLogServer.c:145: undefined reference to
> > > `_imp__epicsSocketConvertErrnoToString'
> > > > C:\hill\epicsInBazaar\epicsR3.15-atomics-small-
> > > fixes\trunk\src\libCom\O.win32-x86-
> > > mingw/../../../src/libCom/log/iocLogServer.c:146: undefined reference to
> > > `_imp__epicsGetStderr@0'
> > > > C:\hill\epicsInBazaar\epicsR3.15-atomics-small-
> > > fixes\trunk\src\libCom\O.win32-x86-
> > > mingw/../../../src/libCom/log/iocLogServer.c:147: undefined reference to
> > > `_imp__epicsGetStderr@0'
> > > > C:\hill\epicsInBazaar\epicsR3.15-atomics-small-
> > > fixes\trunk\src\libCom\O.win32-x86-
> > > mingw/../../../src/libCom/log/iocLogServer.c:157: undefined reference to
> > > `_imp__epicsSocketConvertErrnoToString'
> > > > C:\hill\epicsInBazaar\epicsR3.15-atomics-small-
> > > fixes\trunk\src\libCom\O.win32-x86-
> > > mingw/../../../src/libCom/log/iocLogServer.c:158: undefined reference to
> > > `_imp__epicsGetStderr@0'
> > > > C:\hill\epicsInBazaar\epicsR3.15-atomics-small-
> > > fixes\trunk\src\libCom\O.win32-x86-
> > > mingw/../../../src/libCom/log/iocLogServer.c:173: undefined reference to
> > > `_imp__epicsSocketConvertErrnoToString'
> > > > C:\hill\epicsInBazaar\epicsR3.15-atomics-small-
> > > fixes\trunk\src\libCom\O.win32-x86-
> > > mingw/../../../src/libCom/log/iocLogServer.c:174: undefined reference to
> > > `_imp__epicsGetStderr@0'
> > > > C:\hill\epicsInBazaar\epicsR3.15-atomics-small-
> > > fixes\trunk\src\libCom\O.win32-x86-
> > > mingw/../../../src/libCom/log/iocLogServer.c:187: undefined reference to
> > > `_imp__epicsGetStderr@0'
> > >
> > > I can build the 3.15 tip all the way to the end with no errors with both
> > > MinGW (actually using the gcc from Strawberry Perl, but the GnuWin32
> > > version of make 3.81), and MSVC2010 (again using GnuWin32's make).
> The
> > > gmake 3.82 that comes with Strawberry Perl doesn't support $* properly,
> > > which is a shame as it provides everything else. I do get lots of
> > > warnings from aitConvert.h, plus a handful from elsewhere.
> > >
> > > Try compiling using cmd.exe and with a minimal path -- here's how I set
> > > my path for win32-x86-mingw (after setting EPICS_BASE):
> > >
> > > > @ECHO OFF
> > > >
> > > > REM ---- Windows
> > > > set
> > > PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem
> > > >
> > > > REM ---- Strawberry Tools
> > > > set PATH=%PATH%;C:\strawberry\c\bin
> > > >
> > > > REM ---- Strawberry Perl
> > > > set PATH=%PATH%;C:\strawberry\perl\site\bin;C:\strawberry\perl\bin
> > > >
> > > > REM ---- GnuWin32 Make
> > > > set PATH=%PATH%;D:\Applications\GnuWin32\bin
> > > >
> > > > REM ---- Vim 7.1
> > > > set PATH=%PATH%;Z:\Vim\vim71
> > > >
> > > > REM ---- Bazaar
> > > > set PATH=%PATH%;D:\Applications\Bazaar
> > > >
> > > > REM ---- EPICS
> > > > set EPICS_HOST_ARCH=win32-x86-mingw
> > > >
> > > > set PATH=%PATH%;%EPICS_BASE%\bin\%EPICS_HOST_ARCH%
> > > >
> > > > cd %EPICS_BASE%
> > > > ECHO Configured for %EPICS_HOST_ARCH% with Strawberry tools
> > >
> > > and for win32-x86:
> > >
> > > > @ECHO OFF
> > > >
> > > > REM ---- Windows
> > > > set
> > > PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem
> > > >
> > > > REM ---- Strawberry Tools
> > > > set PATH=%PATH%;C:\strawberry\c\bin
> > > >
> > > > REM ---- Strawberry Perl
> > > > set PATH=%PATH%;C:\strawberry\perl\site\bin;C:\strawberry\perl\bin
> > > >
> > > > REM ---- GnuWin32 Make
> > > > set PATH=%PATH%;D:\Applications\GnuWin32\bin
> > > >
> > > > REM ---- Vim 7.1
> > > > set PATH=%PATH%;Z:\Vim\vim71
> > > >
> > > > REM ---- Bazaar
> > > > set PATH=%PATH%;D:\Applications\Bazaar
> > > >
> > > > REM ---- Visual Studio 2010
> > > > call "C:\Program Files (x86)\Microsoft Visual Studio
> > > 10.0\VC\bin\vcvars32.bat"
> > > >
> > > > REM ---- EPICS
> > > > set EPICS_HOST_ARCH=win32-x86
> > > >
> > > > set PATH=%PATH%;%EPICS_BASE%\bin\%EPICS_HOST_ARCH%
> > > >
> > > > cd %EPICS_BASE%
> > > > ECHO Configured for %EPICS_HOST_ARCH% with Strawberry tools
> > >
> > > There might still be some name decorations that we have wrong, but I
> > > don't see any on Linux where I build 3.15 with -fvisibility=hidden (see
> > > comments in shareLib.h).
> > >
> > > - Andrew
> > > --
> > > Advertising may be described as the science of arresting the human
> > > intelligence long enough to get money from it. -- Stephen Leacock

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System