[llvm-commits] [parallel] CVS: llvm/runtime/zlib/win32/DLL_FAQ.txt Makefile.bor Makefile.emx Makefile.gcc Makefile.msc zlib.def zlib1.rc
Misha Brukman
brukman at cs.uiuc.edu
Mon Mar 1 18:18:17 PST 2004
Changes in directory llvm/runtime/zlib/win32:
DLL_FAQ.txt added (r1.1.2.1)
Makefile.bor added (r1.1.2.1)
Makefile.emx added (r1.1.2.1)
Makefile.gcc added (r1.1.2.1)
Makefile.msc added (r1.1.2.1)
zlib.def added (r1.1.2.1)
zlib1.rc added (r1.1.2.1)
---
Log message:
Merge from trunk
---
Diffs of the changes: (+913 -0)
Index: llvm/runtime/zlib/win32/DLL_FAQ.txt
diff -c /dev/null llvm/runtime/zlib/win32/DLL_FAQ.txt:1.1.2.1
*** /dev/null Mon Mar 1 17:58:59 2004
--- llvm/runtime/zlib/win32/DLL_FAQ.txt Mon Mar 1 17:58:48 2004
***************
*** 0 ****
--- 1,371 ----
+
+ Frequently Asked Questions about ZLIB1.DLL
+
+
+ This document describes the design, the rationale, and the usage
+ of the official DLL build of zlib, named ZLIB1.DLL. If you have
+ general questions about zlib, you should see the file "FAQ" found
+ in the zlib distribution, or at the following location:
+ http://www.gzip.org/zlib/zlib_faq.html
+
+
+ 1. What is ZLIB1.DLL, and how can I get it?
+
+ - ZLIB1.DLL is the official build of zlib as a DLL.
+ (Please remark the symbol '1' in the name.)
+
+ Pointers to a precompiled ZLIB1.DLL can be found in the zlib
+ web site at:
+ http://www.zlib.org/
+
+ Applications that link to ZLIB1.DLL can rely on the following
+ specification:
+
+ * The exported symbols are exclusively defined in the source
+ files "zlib.h" and "zlib.def", found in an official zlib
+ source distribution.
+ * The symbols are exported by name, not by ordinal.
+ * The exported names are undecorated.
+ * The calling convention of functions is "C" (CDECL).
+ * The ZLIB1.DLL binary is linked to MSVCRT.DLL.
+
+ The archive in which ZLIB1.DLL is bundled contains compiled
+ test programs that must run with a valid build of ZLIB1.DLL.
+ It is recommended to download the prebuilt DLL from the zlib
+ web site, instead of building it yourself, to avoid potential
+ incompatibilities that could be introduced by your compiler
+ and build settings. If you do build the DLL yourself, please
+ make sure that it complies with all the above requirements,
+ and it runs with the precompiled test programs, bundled with
+ the original ZLIB1.DLL distribution and available at the zlib
+ web site.
+
+ If, for any reason, you need to build an incompatible DLL,
+ please use a different name.
+
+
+ 2. Why did you change the name of the DLL to ZLIB1.DLL?
+ What happened to the old ZLIB.DLL?
+
+ - The old ZLIB.DLL, built from zlib-1.1.x and earlier, required
+ compilation settings that were incompatible to those used by a
+ static build. The DLL settings were supposed to be enabled by
+ defining the macro ZLIB_DLL, before including "zlib.h".
+ Incorrect handling of this macro was silently accepted at
+ build time, resulting in two major problems:
+
+ * ZLIB_DLL was missing from the old makefile. When building
+ the DLL, not all people added it to the build options. In
+ consequence, incompatible incarnations of ZLIB.DLL started
+ to circulate around the net.
+
+ * When switching from using the static library to using the
+ DLL, applications had to define the ZLIB_DLL macro and
+ to recompile all the sources that contained calls to zlib
+ functions. Failure to do so resulted in creating binaries
+ that were unable to run with the official ZLIB.DLL build.
+
+ The only possible solution that we could foresee was to make a
+ binary-incompatible change in the DLL interfacing, in order to
+ remove the dependency on the ZLIB_DLL macro, and to release
+ the new DLL under a different name.
+
+ We chose the name ZLIB1.DLL, where '1' indicates the major
+ zlib version number. We hope that we will not have to break
+ the binary compatibility again, at least not as long as the
+ zlib-1.x series will last.
+
+ There is still a ZLIB_DLL macro, that can trigger a more
+ efficient build and use of the DLL, but compatibility no
+ longer dependents on it.
+
+
+ 3. Can I build ZLIB.DLL from the new zlib sources, and replace
+ an old ZLIB.DLL, that was built from zlib-1.1.4 or earlier?
+
+ - In principle, you can do it by assigning calling convention
+ keywords to the macros ZEXPORT and ZEXPORTVA. In practice,
+ it depends on what you mean by "an old ZLIB.DLL", because
+ the old DLL exists in several mutually-incompatible versions.
+
+ If you have a compiled application that works with a certain
+ ZLIB.DLL without any known security issues, there is hardly
+ a need to rebuild the DLL from new sources only to link it to
+ the old app binary. But if you really want to do it, you have
+ to find out first what kind of calling convention uses your
+ particular ZLIB.DLL build, and to use the same one in the new
+ build. If you don't know what this is all about, you might be
+ better off if you would just forget it.
+
+
+ 4. Can I compile my application using the new zlib interface, and
+ link it to an old ZLIB.DLL, that was built from zlib-1.1.4 or
+ earlier?
+
+ - The official answer is "no"; the real answer depends again on
+ what kind of ZLIB.DLL you have. Even if you are lucky, this
+ course of action is unreliable.
+
+ If you rebuild your application and you intend to use a newer
+ version of zlib (post- 1.1.4), it is strongly recommended to
+ link it to the new ZLIB1.DLL.
+
+
+ 5. Why are the zlib symbols exported by name, and not by ordinal?
+
+ - Although exporting symbols by ordinal is a little faster, it
+ is risky. Any single glitch in the maintenance or use of the
+ DEF file that contains the ordinals can result in incompatible
+ builds and frustrating crashes. Simply put, the benefits of
+ exporting symbols by ordinal do not justify the risks.
+
+ Technically, it should be possible to maintain ordinals in
+ the DEF file, and still export the symbols by name. Ordinals
+ exist in every DLL, and even if the dynamic linking performed
+ at the DLL startup is searching for names, ordinals serve as
+ hints, for a faster name lookup. However, if the DEF file
+ contains ordinals, the Microsoft linker automatically builds
+ an implib that will cause the executables linked to it to use
+ those ordinals, and not the names. It is interesting to
+ notice that the GNU linker for Win32 does not suffer from this
+ problem.
+
+ It is possible to avoid the DEF file if the exported symbols
+ are accompanied by a "__declspec(dllexport)" attribute in the
+ source files. You can do this in zlib by predefining the
+ ZLIB_DLL macro.
+
+
+ 6. I see that the ZLIB1.DLL functions use the "C" (CDECL) calling
+ convention. Why not use the STDCALL convention?
+ STDCALL is the standard convention in Win32, and I need it in
+ my Visual Basic project!
+
+ (For readability, we use CDECL to refer to the convention
+ triggered by the "__cdecl" keyword, STDCALL to refer to
+ the convention triggered by "__stdcall", and FASTCALL to
+ refer to the convention triggered by "__fastcall".)
+
+ - Most of the native Windows API functions (without varargs) use
+ indeed the WINAPI convention (which translates to STDCALL in
+ Win32), but the standard C functions use CDECL. If a user
+ application is intrinsically tied to the Windows API (e.g.
+ it calls native Windows API functions such as CreateFile()),
+ sometimes it makes sense to decorate its own functions with
+ WINAPI. But if ANSI C or POSIX portability is a goal (e.g.
+ it calls standard C functions such as fopen()), it is not a
+ sound decision to request the inclusion of <windows.h>, or to
+ use non-ANSI constructs, for the sole purpose to make the user
+ functions STDCALL-able.
+
+ The functionality offered by zlib is not in the category of
+ "Windows functionality", but is more like "C functionality".
+
+ Technically, STDCALL is not bad; in fact, it is slightly
+ faster than CDECL, and it works with variable-argument
+ functions, just like CDECL. It is unfortunate that, in spite
+ of using STDCALL in the Windows API, it is not the default
+ convention used by the C compilers that run under Windows.
+ The roots of the problem reside deep inside the unsafety of
+ the K&R-style function prototypes, where the argument types
+ are not specified; but that is another story for another day.
+
+ The fact that remains is that CDECL is the default convention.
+ Even if an explicit convention (such as STDCALL or FASTCALL)
+ is hard-coded into the function prototypes inside C headers,
+ problems may appear. One problem, for example, deals with the
+ necessity to expose the convention in users' callbacks.
+
+ The calling convention issues are also important when using
+ zlib in other programming languages. Some of them, like Ada
+ (GNAT) and Fortran (GNU G77), have C bindings implemented
+ initially on Unix, and relying on the C calling convention.
+ On the other hand, the pre- .NET versions of Microsoft Visual
+ Basic require STDCALL, while Borland Delphi prefers (although
+ it does not require) FASTCALL.
+
+ In fairness to all possible uses of zlib outside the C
+ programming language, we choose the default "C" convention.
+ Anyone interested in different bindings or conventions is
+ encouraged to maintain specialized projects. The "contrib/"
+ directory from the zlib distribution already holds a couple
+ of foreign bindings, such as Ada, C++, and Delphi.
+
+
+ 7. I need a DLL for my Visual Basic project. What can I do?
+
+ - Define the ZLIB_WINAPI macro before including "zlib.h", when
+ building both the DLL and the user application (except that
+ you don't need to define anything when using the DLL in Visual
+ Basic). The ZLIB_WINAPI macro will switch on the WINAPI
+ (STDCALL) convention. The name of this DLL must be different
+ than the official ZLIB1.DLL.
+
+ Gilles Vollant has contributed a build named ZLIBWAPI.DLL,
+ with the ZLIB_WINAPI macro turned on, and with the minizip
+ functionality built in. For more information, please read
+ the notes inside "contrib/vstudio/readme.txt", found in the
+ zlib distribution.
+
+
+ 8. If my application uses ZLIB1.DLL, should I link it to
+ MSVCRT.DLL? Why?
+
+ - It is not required, but it is recommended to link your
+ application to MSVCRT.DLL, if it uses ZLIB1.DLL.
+
+ The executables (.EXE, .DLL, etc.) that are involved in the
+ same process and are using the C run-time library (i.e. they
+ are calling standard C functions), must link to the same
+ library. There are several libraries in the Win32 system:
+ CRTDLL.DLL, MSVCRT.DLL, the static C libraries, etc.
+ Since ZLIB1.DLL is linked to MSVCRT.DLL, the executables that
+ depend on it should also be linked to MSVCRT.DLL.
+
+
+ 9. Why are you saying that ZLIB1.DLL and my application must be
+ linked to the same C run-time (CRT) library? I linked my
+ application and my DLLs to different C libraries (e.g. my
+ application to a static library, and my DLLs to MSVCRT.DLL),
+ and everything works fine.
+
+ - If a user library invokes only pure Win32 API (accessible via
+ <windows.h> and the related headers), its DLL build will work
+ in any context. But if this library invokes standard C API,
+ things get more complicated.
+
+ There is a single Win32 library in a Win32 system. Every
+ function in this library resides in a single DLL module, that
+ is safe to call from anywhere. On the other hand, there are
+ multiple versions of the C library, and each of them has its
+ own separate internal state. Standalone executables and user
+ DLLs that call standard C functions must link to a C run-time
+ (CRT) library, be it static or shared (DLL). Intermixing
+ occurs when an executable (not necessarily standalone) and a
+ DLL are linked to different CRTs, and both are running in the
+ same process.
+
+ Intermixing multiple CRTs is possible, as long as their
+ internal states are kept intact. The Microsoft Knowledge Base
+ articles KB94248 "HOWTO: Use the C Run-Time" and KB140584
+ "HOWTO: Link with the Correct C Run-Time (CRT) Library"
+ mention the potential problems raised by intermixing.
+
+ If intermixing works for you, it's because your application
+ and DLLs are avoiding the corruption of each of the CRTs'
+ internal states, maybe by careful design, or maybe by fortune.
+
+ Also note that linking ZLIB1.DLL to non-Microsoft CRTs (such
+ as those provided by Borland) raises similar problems.
+
+
+ 10. Why are you linking ZLIB1.DLL to MSVCRT.DLL?
+
+ - MSVCRT.DLL exists on every Windows 95 with a new service pack
+ installed, or with Microsoft Internet Explorer 4 or later, and
+ on all other Windows 4.x or later (Windows 98, Windows NT 4,
+ or later). It is freely distributable; if not present in the
+ system, it can be downloaded from Microsoft or from other
+ software provider for free.
+
+ The fact that MSVCRT.DLL does not exist on a virgin Windows 95
+ is not so problematic. The number of Windows 95 installations
+ is rapidly decreasing, Microsoft stopped supporting it a long
+ time ago, and many recent applications from various vendors,
+ including Microsoft, do not even run on it. Furthermore, no
+ serious user should run Windows 95 without a proper update
+ installed.
+
+ There is also the fact that the mainstream C compilers for
+ Windows are Microsoft Visual C++ 6.0, and gcc/MinGW. Both
+ are producing executables that link to MSVCRT.DLL by default,
+ without offering other dynamic CRTs as alternatives easy to
+ select by users.
+
+
+ 11. Why are you not linking ZLIB1.DLL to
+ <<my favorite C run-time library>> ?
+
+ - We considered and abandoned the following alternatives:
+
+ * Linking ZLIB1.DLL to a static C library (LIBC.LIB, or
+ LIBCMT.LIB) is not a good option. People are using the DLL
+ mainly to save disk space. If you are linking your program
+ to a static C library, you may as well consider linking zlib
+ in statically, too.
+
+ * Linking ZLIB1.DLL to CRTDLL.DLL looks very appealing,
+ because CRTDLL.DLL is present on every Win32 installation.
+ Unfortunately, it has a series of problems: it raises
+ difficulties when using it with C++ code, it does not work
+ with 64-bit file offsets, (and so on...), and Microsoft
+ discontinued its support a long time ago.
+
+ * Linking ZLIB1.DLL to MSVCR70.DLL, supplied with the
+ Microsoft .NET platform and Visual C++ 7.0 or newer, is not
+ a good option. Although it is available for free download
+ and distribution, its presence is scarce on today's Win32
+ installations. If it will ever become more popular than
+ MSVCRT.DLL and will be pre-installed on the future Win32
+ systems, we will probably think again about it.
+
+ * Linking ZLIB1.DLL to NTDLL.DLL is not possible.
+ NTDLL.DLL exports only a part of the C library, and only on
+ Windows NT systems.
+
+
+ 12. I need to link my own DLL build to a CRT different than
+ MSVCRT.DLL. What can I do?
+
+ - Feel free to rebuild the DLL from the zlib sources, and link
+ it the way you want. You should, however, clearly state that
+ your build is unofficial. You should give it a different file
+ name, and/or install it in a private directory that can be
+ accessed by your application only, and is not visible to the
+ others (e.g. it's not in the SYSTEM or the SYSTEM32 directory,
+ and it's not in the PATH). Otherwise, your build may clash
+ with applications that link to the official build.
+
+ For example, in Cygwin, zlib is linked to the Cygwin runtime
+ CYGWIN1.DLL, and it is distributed under the name CYGZ.DLL.
+
+
+ 13. May I include additional pieces of code that I find useful,
+ link them in ZLIB1.DLL, and export them?
+
+ - No. A legitimate build of ZLIB1.DLL must not include code
+ that does not originate from the official zlib source code.
+ But you can make your own private DLL build, under a different
+ file name, as suggested in the previous answer.
+
+ For example, in Borland Delphi and C++ Builder, zlib is a part
+ of the standard VCL library. If an application links to VCL
+ dynamically, the name of the distributable binary (VCLxx.DLL)
+ does not posess any danger of clashing with a legitimate but
+ incompatible ZLIB1.DLL.
+
+
+ 14. May I remove some functionality out of ZLIB1.DLL, by enabling
+ macros like NO_GZCOMPRESS or NO_GZIP at compile time?
+
+ - No. A legitimate build of ZLIB1.DLL must provide the complete
+ zlib functionality, as implemented in the official zlib source
+ code. But you can make your own private DLL build, under a
+ different file name, as suggested in the previous answer.
+
+
+ 15. I made my own ZLIB1.DLL build. Can I test it for compliance?
+
+ - We prefer that you download the official DLL from the zlib
+ web site. If you need something peculiar from this DLL, you
+ can send your suggestion to the zlib mailing list.
+
+ However, in case you do rebuild the DLL yourself, you can run
+ it with the test programs found in the DLL distribution.
+ Running these test programs is not a guarantee of compliance,
+ but a failure can imply a detected problem.
+
+ **
+
+ This document is written and maintained by
+ Cosmin Truta <cosmint at cs.ubbcluj.ro>
Index: llvm/runtime/zlib/win32/Makefile.bor
diff -c /dev/null llvm/runtime/zlib/win32/Makefile.bor:1.1.2.1
*** /dev/null Mon Mar 1 17:58:59 2004
--- llvm/runtime/zlib/win32/Makefile.bor Mon Mar 1 17:58:48 2004
***************
*** 0 ****
--- 1,107 ----
+ # Makefile for zlib
+ # Borland C++ for Win32
+ #
+ # Updated for zlib 1.2.x by Cosmin Truta, 11-Mar-2003
+ # Last updated: 28-Aug-2003
+ #
+ # Usage:
+ # make -f win32/Makefile.bor
+ # make -f win32/Makefile.bor LOCAL_ZLIB=-DASMV OBJA=match.obj OBJPA=+match.obj
+
+ # ------------ Borland C++ ------------
+
+ # Optional nonstandard preprocessor flags (e.g. -DMAX_MEM_LEVEL=7)
+ # should be added to the environment via "set LOCAL_ZLIB=-DFOO" or
+ # added to the declaration of LOC here:
+ LOC = $(LOCAL_ZLIB)
+
+ CC = bcc32
+ AS = bcc32
+ LD = bcc32
+ AR = tlib
+ CFLAGS = -a -d -k- -O2 $(LOC)
+ ASFLAGS = $(LOC)
+ LDFLAGS = $(LOC)
+
+
+ # variables
+ ZLIB_LIB = zlib.lib
+
+ OBJ1 = adler32.obj compress.obj crc32.obj deflate.obj gzio.obj infback.obj
+ OBJ2 = inffast.obj inflate.obj inftrees.obj trees.obj uncompr.obj zutil.obj
+ #OBJA =
+ OBJP1 = +adler32.obj+compress.obj+crc32.obj+deflate.obj+gzio.obj+infback.obj
+ OBJP2 = +inffast.obj+inflate.obj+inftrees.obj+trees.obj+uncompr.obj+zutil.obj
+ #OBJPA=
+
+
+ # targets
+ all: $(ZLIB_LIB) example.exe minigzip.exe
+
+ .c.obj:
+ $(CC) -c $(CFLAGS) $<
+
+ .asm.obj:
+ $(AS) -c $(ASFLAGS) $<
+
+ adler32.obj: adler32.c zlib.h zconf.h
+
+ compress.obj: compress.c zlib.h zconf.h
+
+ crc32.obj: crc32.c zlib.h zconf.h crc32.h
+
+ deflate.obj: deflate.c deflate.h zutil.h zlib.h zconf.h
+
+ gzio.obj: gzio.c zutil.h zlib.h zconf.h
+
+ infback.obj: infback.c zutil.h zlib.h zconf.h inftrees.h inflate.h \
+ inffast.h inffixed.h
+
+ inffast.obj: inffast.c zutil.h zlib.h zconf.h inftrees.h inflate.h \
+ inffast.h
+
+ inflate.obj: inflate.c zutil.h zlib.h zconf.h inftrees.h inflate.h \
+ inffast.h inffixed.h
+
+ inftrees.obj: inftrees.c zutil.h zlib.h zconf.h inftrees.h
+
+ trees.obj: trees.c zutil.h zlib.h zconf.h deflate.h trees.h
+
+ uncompr.obj: uncompr.c zlib.h zconf.h
+
+ zutil.obj: zutil.c zutil.h zlib.h zconf.h
+
+ example.obj: example.c zlib.h zconf.h
+
+ minigzip.obj: minigzip.c zlib.h zconf.h
+
+
+ # For the sake of the old Borland make,
+ # the command line is cut to fit in the MS-DOS 128 byte limit:
+ $(ZLIB_LIB): $(OBJ1) $(OBJ2) $(OBJA)
+ -del $(ZLIB_LIB)
+ $(AR) $(ZLIB_LIB) $(OBJP1)
+ $(AR) $(ZLIB_LIB) $(OBJP2)
+ $(AR) $(ZLIB_LIB) $(OBJPA)
+
+
+ # testing
+ test: example.exe minigzip.exe
+ example
+ echo hello world | minigzip | minigzip -d
+
+ example.exe: example.obj $(ZLIB_LIB)
+ $(LD) $(LDFLAGS) example.obj $(ZLIB_LIB)
+
+ minigzip.exe: minigzip.obj $(ZLIB_LIB)
+ $(LD) $(LDFLAGS) minigzip.obj $(ZLIB_LIB)
+
+
+ # cleanup
+ clean:
+ -del *.obj
+ -del *.lib
+ -del *.exe
+ -del *.tds
+ -del zlib.bak
+ -del foo.gz
Index: llvm/runtime/zlib/win32/Makefile.emx
diff -c /dev/null llvm/runtime/zlib/win32/Makefile.emx:1.1.2.1
*** /dev/null Mon Mar 1 17:58:59 2004
--- llvm/runtime/zlib/win32/Makefile.emx Mon Mar 1 17:58:48 2004
***************
*** 0 ****
--- 1,69 ----
+ # Makefile for zlib. Modified for emx/rsxnt by Chr. Spieler, 6/16/98.
+ # Copyright (C) 1995-1998 Jean-loup Gailly.
+ # For conditions of distribution and use, see copyright notice in zlib.h
+
+ # To compile, or to compile and test, type:
+ #
+ # make -fmakefile.emx; make test -fmakefile.emx
+ #
+
+ CC=gcc -Zwin32
+
+ #CFLAGS=-MMD -O
+ #CFLAGS=-O -DMAX_WBITS=14 -DMAX_MEM_LEVEL=7
+ #CFLAGS=-MMD -g -DDEBUG
+ CFLAGS=-MMD -O3 $(BUTT) -Wall -Wwrite-strings -Wpointer-arith -Wconversion \
+ -Wstrict-prototypes -Wmissing-prototypes
+
+ # If cp.exe is available, replace "copy /Y" with "cp -fp" .
+ CP=copy /Y
+ # If gnu install.exe is available, replace $(CP) with ginstall.
+ INSTALL=$(CP)
+ # The default value of RM is "rm -f." If "rm.exe" is found, comment out:
+ RM=del
+ LDLIBS=-L. -lzlib
+ LD=$(CC) -s -o
+ LDSHARED=$(CC)
+
+ INCL=zlib.h zconf.h
+ LIBS=zlib.a
+
+ AR=ar rcs
+
+ prefix=/usr/local
+ exec_prefix = $(prefix)
+
+ OBJS = adler32.o compress.o crc32.o gzio.o uncompr.o deflate.o trees.o \
+ zutil.o inflate.o infback.o inftrees.o inffast.o
+
+ TEST_OBJS = example.o minigzip.o
+
+ all: example.exe minigzip.exe
+
+ test: all
+ ./example
+ echo hello world | .\minigzip | .\minigzip -d
+
+ %.o : %.c
+ $(CC) $(CFLAGS) -c $< -o $@
+
+ zlib.a: $(OBJS)
+ $(AR) $@ $(OBJS)
+
+ %.exe : %.o $(LIBS)
+ $(LD) $@ $< $(LDLIBS)
+
+
+ .PHONY : clean
+
+ clean:
+ $(RM) *.d
+ $(RM) *.o
+ $(RM) *.exe
+ $(RM) zlib.a
+ $(RM) foo.gz
+
+ DEPS := $(wildcard *.d)
+ ifneq ($(DEPS),)
+ include $(DEPS)
+ endif
Index: llvm/runtime/zlib/win32/Makefile.gcc
diff -c /dev/null llvm/runtime/zlib/win32/Makefile.gcc:1.1.2.1
*** /dev/null Mon Mar 1 17:58:59 2004
--- llvm/runtime/zlib/win32/Makefile.gcc Mon Mar 1 17:58:48 2004
***************
*** 0 ****
--- 1,141 ----
+ # Makefile for zlib, derived from Makefile.dj2.
+ # Modified for mingw32 by C. Spieler, 6/16/98.
+ # Updated for zlib 1.2.x by Christian Spieler and Cosmin Truta, Mar-2003.
+ # Last updated: 1-Aug-2003.
+ # Tested under Cygwin and MinGW.
+
+ # Copyright (C) 1995-2003 Jean-loup Gailly.
+ # For conditions of distribution and use, see copyright notice in zlib.h
+
+ # To compile, or to compile and test, type:
+ #
+ # make -fmakefile.gcc; make test testdll -fmakefile.gcc
+ #
+ # To use the asm code, type:
+ # cp contrib/asm?86/match.S ./match.S
+ # make LOC=-DASMV OBJA=match.o -fmakefile.gcc
+ #
+ # To install libz.a, zconf.h and zlib.h in the system directories, type:
+ #
+ # make install -fmakefile.gcc
+
+ # Note:
+ # If the platform is *not* MinGW (e.g. it is Cygwin or UWIN),
+ # the DLL name should be changed from "zlib1.dll".
+
+ STATICLIB = libz.a
+ SHAREDLIB = zlib1.dll
+ IMPLIB = libzdll.a
+
+ #LOC = -DASMV
+ #LOC = -DDEBUG -g
+
+ CC = gcc
+ CFLAGS = $(LOC) -O3 -Wall
+
+ AS = $(CC)
+ ASFLAGS = $(LOC) -Wall
+
+ LD = $(CC)
+ LDFLAGS = $(LOC) -s
+
+ AR = ar
+ ARFLAGS = rcs
+
+ RC = windres
+ RCFLAGS = --define GCC_WINDRES
+
+ CP = cp -fp
+ # If GNU install is available, replace $(CP) with install.
+ INSTALL = $(CP)
+ RM = rm -f
+
+ prefix = /usr/local
+ exec_prefix = $(prefix)
+
+ OBJS = adler32.o compress.o crc32.o deflate.o gzio.o infback.o \
+ inffast.o inflate.o inftrees.o trees.o uncompr.o zutil.o
+ OBJA =
+
+ all: $(STATICLIB) $(SHAREDLIB) $(IMPLIB) example minigzip example_d minigzip_d
+
+ test: example minigzip
+ ./example
+ echo hello world | ./minigzip | ./minigzip -d
+
+ testdll: example_d minigzip_d
+ ./example_d
+ echo hello world | ./minigzip_d | ./minigzip_d -d
+
+ .c.o:
+ $(CC) $(CFLAGS) -c -o $@ $<
+
+ .S.o:
+ $(AS) $(ASFLAGS) -c -o $@ $<
+
+ $(STATICLIB): $(OBJS) $(OBJA)
+ $(AR) $(ARFLAGS) $@ $(OBJS) $(OBJA)
+
+ $(IMPLIB): $(SHAREDLIB)
+
+ $(SHAREDLIB): win32/zlib.def $(OBJS) $(OBJA) zlibrc.o
+ dllwrap --driver-name $(CC) --def win32/zlib.def \
+ --implib $(IMPLIB) -o $@ $(OBJS) $(OBJA) zlibrc.o
+ strip $@
+
+ example: example.o $(STATICLIB)
+ $(LD) $(LDFLAGS) -o $@ example.o $(STATICLIB)
+
+ minigzip: minigzip.o $(STATICLIB)
+ $(LD) $(LDFLAGS) -o $@ minigzip.o $(STATICLIB)
+
+ example_d: example.o $(IMPLIB)
+ $(LD) $(LDFLAGS) -o $@ example.o $(IMPLIB)
+
+ minigzip_d: minigzip.o $(IMPLIB)
+ $(LD) $(LDFLAGS) -o $@ minigzip.o $(IMPLIB)
+
+ zlibrc.o: win32/zlib1.rc
+ $(RC) $(RCFLAGS) -o $@ win32/zlib1.rc
+
+
+ # INCLUDE_PATH and LIBRARY_PATH must be set.
+
+ .PHONY: install uninstall clean
+
+ install: zlib.h zconf.h $(LIB)
+ - at if not exist $(INCLUDE_PATH)/nul mkdir $(INCLUDE_PATH)
+ - at if not exist $(LIBRARY_PATH)/nul mkdir $(LIBRARY_PATH)
+ -$(INSTALL) zlib.h $(INCLUDE_PATH)
+ -$(INSTALL) zconf.h $(INCLUDE_PATH)
+ -$(INSTALL) $(STATICLIB) $(LIBRARY_PATH)
+ -$(INSTALL) $(IMPLIB) $(LIBRARY_PATH)
+
+ uninstall:
+ -$(RM) $(INCLUDE_PATH)/zlib.h
+ -$(RM) $(INCLUDE_PATH)/zconf.h
+ -$(RM) $(LIBRARY_PATH)/$(STATICLIB)
+ -$(RM) $(LIBRARY_PATH)/$(IMPLIB)
+
+ clean:
+ -$(RM) $(STATICLIB)
+ -$(RM) $(SHAREDLIB)
+ -$(RM) $(IMPLIB)
+ -$(RM) *.o
+ -$(RM) *.exe
+ -$(RM) foo.gz
+
+ adler32.o: zlib.h zconf.h
+ compress.o: zlib.h zconf.h
+ crc32.o: crc32.h zlib.h zconf.h
+ deflate.o: deflate.h zutil.h zlib.h zconf.h
+ example.o: zlib.h zconf.h
+ gzio.o: zutil.h zlib.h zconf.h
+ inffast.o: zutil.h zlib.h zconf.h inftrees.h inflate.h inffast.h
+ inflate.o: zutil.h zlib.h zconf.h inftrees.h inflate.h inffast.h
+ infback.o: zutil.h zlib.h zconf.h inftrees.h inflate.h inffast.h
+ inftrees.o: zutil.h zlib.h zconf.h inftrees.h
+ minigzip.o: zlib.h zconf.h
+ trees.o: deflate.h zutil.h zlib.h zconf.h trees.h
+ uncompr.o: zlib.h zconf.h
+ zutil.o: zutil.h zlib.h zconf.h
Index: llvm/runtime/zlib/win32/Makefile.msc
diff -c /dev/null llvm/runtime/zlib/win32/Makefile.msc:1.1.2.1
*** /dev/null Mon Mar 1 17:58:59 2004
--- llvm/runtime/zlib/win32/Makefile.msc Mon Mar 1 17:58:48 2004
***************
*** 0 ****
--- 1,126 ----
+ # Makefile for zlib -- Microsoft (Visual) C
+ #
+ # Authors:
+ # Cosmin Truta, 11-Mar-2003
+ # Christian Spieler, 19-Mar-2003
+ #
+ # Last updated:
+ # Cosmin Truta, 27-Aug-2003
+ #
+ # Usage:
+ # nmake -f win32/Makefile.msc (standard build)
+ # nmake -f win32/Makefile.msc LOC=-DFOO (nonstandard build)
+ # nmake -f win32/Makefile.msc LOC=-DASMV OBJA=match.obj (use ASM code)
+
+
+ # optional build flags
+ LOC =
+
+
+ # variables
+ STATICLIB = zlib.lib
+ SHAREDLIB = zlib1.dll
+ IMPLIB = zdll.lib
+
+ CC = cl
+ AS = ml
+ LD = link
+ AR = lib
+ RC = rc
+ CFLAGS = -nologo -MD -O2 $(LOC)
+ ASFLAGS = -coff
+ LDFLAGS = -nologo -release
+ ARFLAGS = -nologo
+ RCFLAGS = /dWIN32 /r
+
+ OBJS = adler32.obj compress.obj crc32.obj deflate.obj gzio.obj infback.obj \
+ inffast.obj inflate.obj inftrees.obj trees.obj uncompr.obj zutil.obj
+ OBJA =
+
+
+ # targets
+ all: $(STATICLIB) $(SHAREDLIB) $(IMPLIB) \
+ example.exe minigzip.exe example_d.exe minigzip_d.exe
+
+ $(STATICLIB): $(OBJS) $(OBJA)
+ $(AR) $(ARFLAGS) -out:$@ $(OBJS) $(OBJA)
+
+ $(IMPLIB): $(SHAREDLIB)
+
+ $(SHAREDLIB): win32/zlib.def $(OBJS) $(OBJA) zlib1.res
+ $(LD) $(LDFLAGS) -def:win32/zlib.def -dll -implib:$(IMPLIB) \
+ -out:$@ $(OBJS) $(OBJA) zlib1.res
+
+ example.exe: example.obj $(STATICLIB)
+ $(LD) $(LDFLAGS) example.obj $(STATICLIB)
+
+ minigzip.exe: minigzip.obj $(STATICLIB)
+ $(LD) $(LDFLAGS) minigzip.obj $(STATICLIB)
+
+ example_d.exe: example.obj $(IMPLIB)
+ $(LD) $(LDFLAGS) -out:$@ example.obj $(IMPLIB)
+
+ minigzip_d.exe: minigzip.obj $(IMPLIB)
+ $(LD) $(LDFLAGS) -out:$@ minigzip.obj $(IMPLIB)
+
+ .c.obj:
+ $(CC) -c $(CFLAGS) $<
+
+ .asm.obj:
+ $(AS) -c $(ASFLAGS) $<
+
+ adler32.obj: adler32.c zlib.h zconf.h
+
+ compress.obj: compress.c zlib.h zconf.h
+
+ crc32.obj: crc32.c zlib.h zconf.h crc32.h
+
+ deflate.obj: deflate.c deflate.h zutil.h zlib.h zconf.h
+
+ gzio.obj: gzio.c zutil.h zlib.h zconf.h
+
+ infback.obj: infback.c zutil.h zlib.h zconf.h inftrees.h inflate.h \
+ inffast.h inffixed.h
+
+ inffast.obj: inffast.c zutil.h zlib.h zconf.h inftrees.h inflate.h \
+ inffast.h
+
+ inflate.obj: inflate.c zutil.h zlib.h zconf.h inftrees.h inflate.h \
+ inffast.h inffixed.h
+
+ inftrees.obj: inftrees.c zutil.h zlib.h zconf.h inftrees.h
+
+ trees.obj: trees.c zutil.h zlib.h zconf.h deflate.h trees.h
+
+ uncompr.obj: uncompr.c zlib.h zconf.h
+
+ zutil.obj: zutil.c zutil.h zlib.h zconf.h
+
+ example.obj: example.c zlib.h zconf.h
+
+ minigzip.obj: minigzip.c zlib.h zconf.h
+
+ zlib1.res: win32/zlib1.rc
+ $(RC) $(RCFLAGS) /fo$@ win32/zlib1.rc
+
+
+ # testing
+ test: example.exe minigzip.exe
+ example
+ echo hello world | minigzip | minigzip -d
+
+ testdll: example_d.exe minigzip_d.exe
+ example_d
+ echo hello world | minigzip_d | minigzip_d -d
+
+
+ # cleanup
+ clean:
+ -del $(STATICLIB)
+ -del $(SHAREDLIB)
+ -del $(IMPLIB)
+ -del *.obj
+ -del *.res
+ -del *.exp
+ -del *.exe
+ -del foo.gz
Index: llvm/runtime/zlib/win32/zlib.def
diff -c /dev/null llvm/runtime/zlib/win32/zlib.def:1.1.2.1
*** /dev/null Mon Mar 1 17:58:59 2004
--- llvm/runtime/zlib/win32/zlib.def Mon Mar 1 17:58:48 2004
***************
*** 0 ****
--- 1,60 ----
+ LIBRARY
+ ; zlib data compression library
+
+ EXPORTS
+ ; basic functions
+ zlibVersion
+ deflate
+ deflateEnd
+ inflate
+ inflateEnd
+ ; advanced functions
+ deflateSetDictionary
+ deflateCopy
+ deflateReset
+ deflateParams
+ deflateBound
+ deflatePrime
+ inflateSetDictionary
+ inflateSync
+ inflateCopy
+ inflateReset
+ inflateBack
+ inflateBackEnd
+ zlibCompileFlags
+ ; utility functions
+ compress
+ compress2
+ compressBound
+ uncompress
+ gzopen
+ gzdopen
+ gzsetparams
+ gzread
+ gzwrite
+ gzprintf
+ gzputs
+ gzgets
+ gzputc
+ gzgetc
+ gzungetc
+ gzflush
+ gzseek
+ gzrewind
+ gztell
+ gzeof
+ gzclose
+ gzerror
+ gzclearerr
+ ; checksum functions
+ adler32
+ crc32
+ ; various hacks, don't look :)
+ deflateInit_
+ deflateInit2_
+ inflateInit_
+ inflateInit2_
+ inflateBackInit_
+ inflateSyncPoint
+ get_crc_table
+ zError
Index: llvm/runtime/zlib/win32/zlib1.rc
diff -c /dev/null llvm/runtime/zlib/win32/zlib1.rc:1.1.2.1
*** /dev/null Mon Mar 1 17:58:59 2004
--- llvm/runtime/zlib/win32/zlib1.rc Mon Mar 1 17:58:48 2004
***************
*** 0 ****
--- 1,39 ----
+ #include <windows.h>
+
+ #ifdef GCC_WINDRES
+ VS_VERSION_INFO VERSIONINFO
+ #else
+ VS_VERSION_INFO VERSIONINFO MOVEABLE IMPURE LOADONCALL DISCARDABLE
+ #endif
+ FILEVERSION 1,2,1,0
+ PRODUCTVERSION 1,2,1,0
+ FILEFLAGSMASK VS_FFI_FILEFLAGSMASK
+ #ifdef _DEBUG
+ FILEFLAGS 1
+ #else
+ FILEFLAGS 0
+ #endif
+ FILEOS VOS_DOS_WINDOWS32
+ FILETYPE VFT_DLL
+ FILESUBTYPE 0 // not used
+ BEGIN
+ BLOCK "StringFileInfo"
+ BEGIN
+ BLOCK "040904E4"
+ //language ID = U.S. English, char set = Windows, Multilingual
+ BEGIN
+ VALUE "FileDescription", "zlib data compression library\0"
+ VALUE "FileVersion", "1.2.1\0"
+ VALUE "InternalName", "zlib1.dll\0"
+ VALUE "LegalCopyright", "(C) 1995-2003 Jean-loup Gailly & Mark Adler\0"
+ VALUE "OriginalFilename", "zlib1.dll\0"
+ VALUE "ProductName", "zlib\0"
+ VALUE "ProductVersion", "1.2.1\0"
+ VALUE "Comments","DLL support by Alessandro Iacopetti & Gilles Vollant\0"
+ END
+ END
+ BLOCK "VarFileInfo"
+ BEGIN
+ VALUE "Translation", 0x0409, 1252
+ END
+ END
More information about the llvm-commits
mailing list