I have a qestion about building units and installing them using the fpcmake system.

In package for Windows, I have some .obj files that the unit requires. How do I make a Makefile.fpc file that installs the .obj files into a package and allows programs using the package to locate the .obj files? In other words, I want to be sure that a developer can use this unit in Windows with no problems if the .obj format is supported . In other words, what entries do I have to make for this?

Before mentioning that the .obj files are not supported, I am aware that this has not been tested. I wish to see if this can work (you don't know until you try). I'm trying to do this with the ZLib library (the most recent version). For Linux, I have verified that the ZLib library works through dynamic loading. On Win32, that may not be desirable since there seems to be several versions of the ZLIB .DLL

J. Peter Mugaas wrote

Before mentioning that the .obj files are not supported, I am aware that this has not been tested. I wish to see if this can work (you don't know until you try). I'm trying to do this with the ZLib library (the most recent version). For Linux, I have verified that the ZLib library works through dynamic loading. On Win32, that may not be desirable since there seems to be several versions of the ZLIB .DLL

Why not use paszlib, if you want to avoid dynamic loading?

Vincent.

Op Tue, 11 Apr 2006, schreef J. Peter Mugaas:

Before mentioning that the .obj files are not supported, I am aware that this has not been tested. I wish to see if this can work (you don't know until you try).

It is not a matter of .obj not been tested, it is a matter of the GNU linker not understanding .obj GNU linker only eats COFF formatted .o files, if you feed it a .obj it will refuse.

I'm trying to do this with the ZLib library (the most recent version). For Linux, I have verified that the ZLib library works through dynamic loading. On Win32, that may not be desirable since there seems to be several versions of the ZLIB .DLL

It is often better to use Paszlib and forget about DLL's and .so's.

Daniël

I already suggested this, and JP's remarks are correct:

- It is very old and several functions he uses are missing.
- This is indy, the lib is possibly linked to the net, security is an issue. Over the years several indy bugs have been fixed, and nobody knows the status of these for paszlib (and how many paszlib introduces, but at least those are somewhat covered by the obscurity thing)

Over the years several indy bugs have been fixed, and nobody knows the

Several zlib bugs I meant here of course, some quite high-profile.

Op Tue, 11 Apr 2006, schreef Marco van de Voort:

> Over the years several indy bugs have been fixed, and nobody knows the Several zlib bugs I meant here of course, some quite high-profile.

Hmmm.... True, but I think that should not stop people from using it; if people do not use our libraries, bugs won't get fixed in them.

Daniël

Note that it shouldn't be difficult to get zlib.a compiled for Win32 target and link to that one if you really want to link to static version.

Furthermore, I believe that linking to a dynamic version should be still possible even on Win32 platform. All platforms are still compiled from the same ZLib sources after all, so you should be still able to check the minimum required version number and/or provide your own binary version within the installation package.

Tomas

J. Peter Mugaas wrote:
[...]

On Win32, that may not be desirable since there seems to be several versions of the ZLIB .DLL

Unfortunately, it's true that there are several (sometimes incompatible -- various zlib versions, various calling conventions) zlib.dll versions floating around.

Fortunately, there exists more-or-less standard zlib dll library for win32. It can be obtained from [http://gnuwin32.sourceforge.net/]. It is frequently updated, so all known security problems should be fixed there. It's used by many programs (including gimp for windows, or actually gtk 2 for windows; oh, and my programs :) ). It's named zlib1.dll (with "1"), so no conflicts with zlib.dll. As far as I am aware, no software dared to ever install incompatible zlib1.dll version. So this may be your solution.

Michalis

I think it goes beyond that. ZLib 1.20 introduced some new functions (it's hard to determine what version yours is because it simply says 1.2).

There are some ZLib 1.20 functions that your paszlib does not support that the standard ZLib libraries support.

Sumary from the changelog:
===
- New and improved inflate code
- About 20% faster
- Does not allocate 32K window unless and until needed
- Automatically detects and decompresses gzip streams
- Raw inflate no longer needs an extra dummy byte at end
- Added inflateBack functions using a callback interface--even faster than inflate, useful for file utilities (gzip, zip)
- Added inflateCopy() function to record state for random access on externally generated deflate streams (e.g. in gzip files)
- More readable code (I hope)
- New and improved crc32()
- Add deflateBound() and compressBound() functions ===
The inflateback functions are much faster than the older inflateinit2_ functions and I use the inflateback functions given their speed.

The header I now have references something that was introduced in ZLib 1.2.0.5 1.2.0.5 - 8 September 200)

Add Z_BLOCK flush option to return from inflate at block boundary

Then the header I have references the following from (1.2.0.1 - 17 March 2003)
- Add Z_RLE strategy for run-length encoding [Truta]
- When Z_RLE requested, restrict matches to distance one
- Update zlib.h, minigzip.c, gzopen(), gzdopen() for Z_RLE

Changes in 1.2.0.2 - 13 July 2003
- Add zlibCompileFlags() function to return compilation information

Usuually, I consider it a good idea to a have a comprehensive header since a lot of headers may wind up being recycled and used in ways you never thought.

And I noticed that the zlib1.dll filename is the same between the official ZLib .DLL and the the one you mentioned. The zlib version you mentioned has a file size of 73.5 KB (75,264 bytes) while the official one has a file size of 58.5 KB (59,904 bytes). What's the key difference between the two? What are the standard calling conventions for them (stdcall or cdecl)?

It might be. I still am biased towards static linking some type of object file (either the .obj form or an .a format) and I noticed that the distribution you mentioned does have libz.a. Does that statically link all the zlib code or do would have to include the .dll? If it does, then I might want to consider that instead. If I go that route, the original question (i'll phrase it a little differently still applies).

===
In package for Windows, I have some object files that the unit requires. How do I make a Makefile.fpc file that installs the object files into a package and allows programs using the package to locate the object files? In other words, I want to be sure that a developer can use this unit in Windows? In other words, what entries do I have to make for this in the Makefile.fpc? ===

I hate to sound argumentative but I'm just trying to approach this very carefully. If push comes to shove, I simply change an IFDEF in the header and document which .DLL to use (I admit that I still do not like solution).

J. Peter Mugaas wrote:
[...]

And I noticed that the zlib1.dll filename is the same between the official ZLib .DLL and the the one you mentioned. The zlib version you mentioned has a file size of 73.5 KB (75,264 bytes) while the official one has a file size of 58.5 KB (59,904 bytes). What's the key difference between the two? What are the standard calling conventions for them (stdcall or cdecl)?

The one on official [http://www.zlib.net/] was compiled with Microsoft Visual C++. While gnuwin32 uses MinGW gcc and binutils for compilation. That's the difference. Fortunately, they both use the same calling convention: cdecl (see DLL_FAQ.txt for official zlib123-dll.zip from [http://www.zlib.net/] and
)
so they should be compatible.

The .a file should contain the same thing as .dll, but for linking statically. Libraries compiled on gnuwin32 (both static and dynamic) use MinGW gcc and binutils for compilation, so they should be compatible with FPC under Win32.

If I were you, I would still use dynamic library (.dll) anyway, because that allows "advanced" users to manually update zlib1.dll your program uses.

Michalis

You'll need to code this yourself in the [rules] section.

Does anyone knows how paszlib compare with zlib.dll regarding speed?

Luiz

Hello,

Just one note.

You don´t need to use a external dll to use the c version. On a Delphi project of mine I use ZLibEx.pas

It is a pascal file that statically imports .o files compiled from the "official" c sources using c++ builder and offers some Stream objects to use ZLib with TFileStream (or other streams you want to use), so it´s really easy to use.

You can download it here:

http://www.dellapasqua.com/delphizlib/

It was created by Borland and Base2 technologies and is the version distributed with Delphi.

There are some issues however:

1 - Windows only

2 - Was made with Delphi in mind, so may need some minor changes to compile with Free Pascal, like adding {$mode delphi}

3 - A set of suitable .o files that are FPC compatible.

(3) is the biggest problem.

Marco van de Voort wrote

3 - A set of suitable .o files that are FPC compatible. (3) is the biggest problem.

What is the format of .o files?

Is it COFF or something like that? Are they all incompatible across compilers?

That is based on ZLib 1.2.2 and ZLib 1.2.2 has a Cert warnings about a security flaws.

http://www.kb.cert.org/vuls/id/238678
http://www.kb.cert.org/vuls/id/680620

ZLib 1.2.3 fixes those. The thing is that FreePascal might not be able to use standard .obj files in Windows (at least that's what everyone was telling me) and that has to do with the ld linker. Even if that does work, there would probably have to some Makefile rules for handling the object files (such as place them in the compiled units dir) and I was told I would have to write my own rules for that and I have not yet been able to do this because I don't know how).

What I had to do was dynamically load a .DLL and document in my readme file where to get it. The one I use is based on the "Enhanced zlib package" from Borland's Code Central (entry ID: 23490) which I then modified for Indy usage and modified so that you can use it in FreePascal. I tested it with an example program in Linux and Win32.

I just happened to download the 1.2.3 ZLibEx version for delphi here: http://www.base2ti.com/cgi-bin/download.exe?folder=delphi+zlib&file=delphi+zlib+1.2.3

Marc

I don't but you may be able to get quite a bit of improvement using the inflateBack, inflateBackEnd, and inflateBackInit_ functions. The one I use is based on the "Enhanced zlib package" from Borland's Code Central (entry ID: 23490) which I then modified for Indy usage and modified so that you can use it in FreePascal. I tested it with an example program in Linux and Win32. If anyone wants to test what I have, please feel free to do so and may be the best code win.

It is part of the source-code downloads that I made last night. The URL is http://www.indyproject.org/sockets/fpc/.