EPICS Home

Experimental Physics and Industrial Control System


 
2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <2013>  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <2013>  2014  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: Andrew Johnson <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Tue, 19 Nov 2013 23:16:59 +0000 
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
Navigate by Date:
Prev: Re: undefined symbols in windows build Andrew Johnson
Next: RE: undefined symbols in windows build Hill, Jeff
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <2013>  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: undefined symbols in windows build Andrew Johnson
Next: RE: undefined symbols in windows build Hill, Jeff
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <2013>  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024