EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: undefined symbols in windows build
From: "Hill, Jeff" <[email protected]>
To: "Hill, Jeff" <[email protected]>, Andrew Johnson <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Tue, 19 Nov 2013 23:49:11 +0000
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



Replies:
RE: undefined symbols in windows build Hill, Jeff
References:
undefined symbols in windows build Hill, Jeff
Re: undefined symbols in windows build Andrew Johnson
RE: undefined symbols in windows build Hill, Jeff

Navigate by Date:
Prev: RE: undefined symbols in windows build Hill, Jeff
Next: RE: undefined symbols in windows build Hill, Jeff
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: undefined symbols in windows build Hill, Jeff
Next: RE: undefined symbols in windows build Hill, Jeff
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 19 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·