I am trying to compile 'make-3.80' on Windows 2000 Advance Server. I download all of the current files as 7/2003. I did attach Readme.gnumake.txt file. Included in this file is my path / lib settings. Compile errors that I am receiving.
I did install MS C++ using the default location "But I removed all white space in file name"
I would appreciate your input in helping me solve this issue. Trying to put up in production Oracle 11i database and need this product for that.
I can be reached by phone or email.
Appreciate all your help
<<README.GNUMAKE.txt>>
Gregory Van Wieren
MCSA 2000, MCSE 2000, MCP+I
Northrop Grumman Information Technology
Office: 269-961-4414
gregory[EMAIL PROTECTED]
Port of GNU make to Windows NT and Windows 95 Builds natively with MSVC 2.x or MSVC 4.x compilers. Should also build fine with MSVC 5.x and 6.x (though not confirmed).
This Windows 32-bit port of GNU make is maintained primarily by Rob
Tulloh, who is also the author of this README.
To build with nmake on Windows NT, Windows 95, or Windows 98:
****************************************************************************
Using Windows 2000 Advance Server SP3
Install MS C++ Removed all space using default names
NOTE: c:\msdev C:\ProgramFiles\Microsoft\VisualStudio\VC98
VCVARS32.bat C:\ProgramFiles\MicrosoftVisualStudio\VC98\bin
Path
C:\ProgramFiles\MicrosoftVisualStudio\VC98\bin;
C:\ProgramFiles\MicrosoftVisualStudio\Common\Tools\WinNT;
C:\ProgramFiles\MicrosoftVisualStudio\Common\MSDev98\Bin;
C:\ProgramFiles\MicrosoftVisualStudio\Common\Tools;
Lib
C:\ProgramFiles\MicrosoftVisualStudio\VC98\lib;
C:\ProgramFiles\MicrosoftVisualStudio\VC98\mfc\lib;
System Var.
c:\Gnumake;
c:\Gnumake\make-3.80;
C:\ProgramFiles\MicrosoftVisualStudio\VC98\bin;
c:\mks\bin;c:\mks\mksnt;
C:\WINNT\system32;
C:\WINNT;
C:\WINNT\System32\Wbem;
c:\ProgramFiles\MicrosoftVisualStudio\Common\Tools\WinNT;
************************************************************************
Errors on the compile
C:\GNUMAKE\make-3.80>nmake /f NMakefile
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
NMAKE /f NMakefile LDFLAGS="w32\subproc\WinRel\subproc.lib /NOLOGO
/SUBSYSTEM:cons
ole /INCREMENTAL:no /MACHINE:I386 /OUT:WinRel/make.exe" CFLAGS="/nologo /MT /W3 /GX
/Zi /Y
X /I . /I glob /I w32/include /D WIN32 /D WINDOWS32 /D _CONSOLE /D HAVE_CONFIG_H /O2
/D ND
EBUG /FR.\WinRel/ /Fp.\WinRel/make.pch /Fo.\WinRel/" OUTDIR=WinRel WinRel/make.exe
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
link @C:\DOCUME~1\HGR021~1.BTL\LOCALS~1\Temp\nma01316.
variable.obj : error LNK2001: unresolved external symbol _hash_init
dir.obj : error LNK2001: unresolved external symbol _hash_init
file.obj : error LNK2001: unresolved external symbol _hash_init
function.obj : error LNK2001: unresolved external symbol _hash_init
read.obj : error LNK2001: unresolved external symbol _hash_init
dir.obj : error LNK2001: unresolved external symbol _hash_insert_at
file.obj : error LNK2001: unresolved external symbol _hash_insert_at
read.obj : error LNK2001: unresolved external symbol _hash_insert_at
variable.obj : error LNK2001: unresolved external symbol _hash_insert_at
dir.obj : error LNK2001: unresolved external symbol _hash_deleted_item
file.obj : error LNK2001: unresolved external symbol _hash_deleted_item
read.obj : error LNK2001: unresolved external symbol _hash_deleted_item
variable.obj : error LNK2001: unresolved external symbol _hash_deleted_item
dir.obj : error LNK2001: unresolved external symbol _hash_find_slot
file.obj : error LNK2001: unresolved external symbol _hash_find_slot
read.obj : error LNK2001: unresolved external symbol _hash_find_slot
variable.obj : error LNK2001: unresolved external symbol _hash_find_slot
dir.obj : error LNK2001: unresolved external symbol _hash_find_item
file.obj : error LNK2001: unresolved external symbol _hash_find_item
function.obj : error LNK2001: unresolved external symbol _hash_find_item
variable.obj : error LNK2001: unresolved external symbol _hash_find_item
dir.obj : error LNK2001: unresolved external symbol _hash_insert
function.obj : error LNK2001: unresolved external symbol _hash_insert
file.obj : error LNK2001: unresolved external symbol _hash_delete
variable.obj : error LNK2001: unresolved external symbol _hash_delete
file.obj : error LNK2001: unresolved external symbol _hash_dump
file.obj : error LNK2001: unresolved external symbol _hash_print_stats
variable.obj : error LNK2001: unresolved external symbol _hash_print_stats
file.obj : error LNK2001: unresolved external symbol _hash_map
variable.obj : error LNK2001: unresolved external symbol _hash_map
function.obj : error LNK2001: unresolved external symbol _hash_free
read.obj : error LNK2001: unresolved external symbol _hash_free
variable.obj : error LNK2001: unresolved external symbol _hash_free
function.obj : error LNK2001: unresolved external symbol _hash_load
variable.obj : error LNK2001: unresolved external symbol _hash_map_arg
WinRel/make.exe : fatal error LNK1120: 13 unresolved externals
NMAKE : fatal error U1077: 'link' : return code '0x460'
Stop.
NMAKE : fatal error U1077: 'C:\ProgramFiles\MicrosoftVisualStudio\VC98\bin\NMAKE.EXE'
: re
turn code '0x2'
Stop.
****************************************************************************
1. Make sure cl.exe is in your %Path%. Example:
set Path=%Path%;c:/msdev/bin
2. Make sure %include% is set to msvc include directory. Example:
set include=c:/msdev/include
3. Make sure %lib% is set to msvc lib directory. Example:
set lib=c:/msdev/lib
4. nmake /f NMakefile
*** Fatal error U1052 Not Find NMakefile
A short cut to steps 1, 2, and 3 is to run VCVARS32.bat before
invoking namke. For example:
c:
cd \msdev\bin
VCVARS32.bat
cd \path\to\make-3.80
nmake /f NMakefile
There is a bat file (build_w32.bat) for folks who have fear of nmake.
Outputs:
WinDebug/make.exe
WinRel/make.exe
-- Notes/Caveats --
GNU make on Windows 32-bit platforms:
This version of make is ported natively to Windows32 platforms
(Windows NT 3.51, Windows NT 4.0, Windows 95, and Windows 98). It
does not rely on any 3rd party software or add-on packages for
building. The only thing needed is a version of Visual C++,
which is the predominant compiler used on Windows32 platforms.
Do not confuse this port of GNU make with other Windows32 projects
which provide a GNU make binary. These are separate projects
and are not connected to this port effort.
GNU make and sh.exe:
This port prefers you have a working sh.exe somewhere on your
system. If you don't have sh.exe, the port falls back to
MSDOS mode for launching programs (via a batch file).
The MSDOS mode style execution has not been tested that
carefully though (The author uses GNU bash as sh.exe).
There are very few true ports of Bourne shell for NT right now.
There is a version of GNU bash available from Cygnus "Cygwin"
porting effort (http://sourceware.cygnus.com/cygwin).
Other possibilities are the MKS version of sh.exe, or building
your own with a package like NutCracker (DataFocus) or Portage
(Consensys).
GNU make and brain-dead shells (BATCH_MODE_ONLY_SHELL):
Some versions of Bourne shell does not behave well when invoked
as 'sh -c' from CreateProcess(). The main problem is they seem
to have a hard time handling quoted strings correctly. This can
be circumvented by writing commands to be executed to a batch
file and then executing the command by calling 'sh file'.
To work around this difficulty, this version of make supports
a batch mode. When BATCH_MODE_ONLY_SHELL is defined at compile
time, make forces all command lines to be executed via script
files instead of by command line.
A native Windows32 system with no Bourne shell will also run
in batch mode. All command lines will be put into batch files
and executed via $(COMSPEC) (%COMSPEC%).
GNU make and Cygnus GNU Windows32 tools:
Good news! Make now has native support for Cygwin sh. To enable,
define the HAVE_CYGWIN_SHELL in config.h and rebuild make
from scratch. This version of make tested with B20.1 of Cygwin.
Do not define BATCH_MODE_ONLY_SHELL if you use HAVE_CYGWIN_SHELL.
GNU make and the MKS shell:
There is now semi-official support for the MKS shell. To turn this
support on, define HAVE_MKS_SHELL in the config.h.W32 before you
build make. Do not define BATCH_MODE_ONLY_SHELL if you turn
on HAVE_MKS_SHELL.
GNU make handling of drive letters in pathnames (PATH, vpath, VPATH):
There is a caveat that should be noted with respect to handling
single character pathnames on Windows systems. When colon is
used in PATH variables, make tries to be smart about knowing when
you are using colon as a separator versus colon as a drive
letter. Unfortunately, something as simple as the string 'x:/'
could be interpreted 2 ways: (x and /) or (x:/).
Make chooses to interpret a letter plus colon (e.g. x:/) as a
drive letter pathname. If it is necessary to use single
character directories in paths (VPATH, vpath, Path, PATH), the
user must do one of two things:
a. Use semicolon as the separator to disambiguate colon. For
example use 'x;/' if you want to say 'x' and '/' are
separate components.
b. Qualify the directory name so that there is more than
one character in the path(s) used. For example, none
of these settings are ambiguous:
./x:./y
/some/path/x:/some/path/y
x:/some/path/x:x:/some/path/y
Please note that you are free to mix colon and semi-colon in the
specification of paths. Make is able to figure out the intended
result and convert the paths internally to the format needed
when interacting with the operating system.
You are encouraged to use colon as the separator character.
This should ease the pain of deciding how to handle various path
problems which exist between platforms. If colon is used on
both Unix and Windows systems, then no ifdef'ing will be
necessary in the makefile source.
GNU make test suite:
I verified all functionality with a slightly modified version
of make-test-3.80 (modifications to get test suite to run
on Windows NT). All tests pass in an environment that includes
sh.exe. Tests were performed on both Windows NT and Windows 95.
Building GNU make on Windows NT and Windows 95/98 with Microsoft Visual C:
I did not provide a Visual C project file with this port as
the project file would not be considered freely distributable
(or so I think). It is easy enough to create one, though, if
you know how to use Visual C.
I build the program statically to avoid problems locating DLL's
on machines that may not have MSVC runtime installed. If you
prefer, you can change make to build with shared libraries by
changing /MT to /MD in the NMakefile (or in build_w32.bat).
The program has not been built for non-Intel architectures (yet).
I have not tried to build with any other compilers than MSVC. I
have heard that this is possible though so don't be afraid to
notify me of your successes!
Pathnames and white space:
Unlike Unix, Windows 95/NT systems encourage pathnames which
contain white space (e.g. C:\Program Files\). These sorts of pathnames
are legal under Unix too, but are never encouraged. There is
at least one place in make (VPATH/vpath handling) where paths
containing white space will simply not work. There may be others
too. I chose to not try and port make in such a way so that
these sorts of paths could be handled. I offer these suggestions
as workarounds:
1. Use 8.3 notation
2. Rename the directory so it does not contain white space.
If you are unhappy with this choice, this is free software
and you are free to take a crack at making this work. The code
in w32/pathstuff.c and vpath.c would be the places to start.
Pathnames and Case insensitivity:
Unlike Unix, Windows 95/NT systems are case insensitive but case
preserving. For example if you tell the file system to create a
file named "Target", it will preserve the case. Subsequent access to
the file with other case permutations will succeed (i.e. opening a
file named "target" or "TARGET" will open the file "Target").
By default, GNU make retains its case sensitivity when comparing
target names and existing files or directories. It can be
configured, however, into a case preserving and case insensitive
mode by adding a define for HAVE_CASE_INSENSITIVE_FS to
config.h.W32.
For example, the following makefile will create a file named
Target in the directory subdir which will subsequently be used
to satisfy the dependency of SUBDIR/DepTarget on SubDir/TARGET.
Without HAVE_CASE_INSENSITIVE_FS configured, the dependency link
will not be made:
subdir/Target:
touch $@
SUBDIR/DepTarget: SubDir/TARGET
cp $^ $@
Reliance on this behavior also eliminates the ability of GNU make
to use case in comparison of matching rules. For example, it is
not possible to set up a C++ rule using %.C that is different
than a C rule using %.c. GNU make will consider these to be the
same rule and will issue a warning.
SAMBA/NTFS/VFAT:
I have not had any success building the debug version of this
package using SAMBA as my file server. The reason seems to be
related to the way VC++ 4.0 changes the case name of the pdb
filename it is passed on the command line. It seems to change
the name always to to lower case. I contend that
the VC++ compiler should not change the casename of files that
are passed as arguments on the command line. I don't think this
was a problem in MSVC 2.x, but I know it is a problem in MSVC 4.x.
The package builds fine on VFAT and NTFS filesystems.
Most all of the development I have done to date has been using
NTFS and long file names. I have not done any considerable work
under VFAT. VFAT users may wish to be aware that this port
of make does respect case sensitivity.
FAT:
Version 3.76 added support for FAT filesystems. Make
works around some difficulties with stat'ing of
files and caching of filenames and directories internally.
Bug reports:
Please submit bugs via the normal bug reporting mechanism which
is described in the GNU make manual and the base README.
_______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
