Date: Fri, 2 Jan 2004 00:04:05 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600
Subject: [UnixOS2_Archive] No. 280

**************************************************
Thursday 01 January 2004
 Number  280
**************************************************

Subjects for today
 
1  Re:  New ZLIB : Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
2  Re: lib vs. dll (was: Re:  Pine problem) : Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
3  Re:  New ZLIB : John Poltorak <jp at warpix.org>
4  Re:  New ZLIB : Dave and Natalie" <dave_yeo at mindlink.bc.ca>
5  Re:  New ZLIB : John Poltorak <jp at warpix.org>
6  Re: lib vs. dll (was: Re:  Pine problem) : Steven Levine" <steve53 at earthlink.net>
7   pthreads : John Poltorak <jp at warpix.org>

**= Email   1 ==========================**

Date:  Wed, 31 Dec 2003 15:16:29 +0100 (CET)
From:  Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
Subject:  Re:  New ZLIB

On Tue, 30 Dec 2003, Dave and Natalie wrote:

> How do you keep the ordinals if some imports have disappeared? Eg, trying to build ZLIB 1.2.1 using
> Hung-Chi Chu's import def. He included some imports that he shouldn't of have and these are gone now. I
> tried commenting them out but now get this error
> LINK386 :  error L2022: ÿ (alias ÿ) : export undefined

Well, hopefully those vanished symbols have never been used (otherwise I
don't see how people could claim backward compatibility on Unix
platforms), so just removing those and keeping the ordinals the same for
the symbols that still exist should be sufficient.

> >2. Even when switching to import by name, the OS/2 port must maintain
> >   the old ordinals, which means no fully automated build is possible.
> 
> How exactly do you move over to import by name and keep the old ordinals?

Well, I had a look at EMX documentation, but I'm still guessing
(hopefully, somebody will correct me, where I'm wrong):
- Create the DLL "as usual" with a suitable ("backward
  compatible") definition file defining ordinals.
- Create the import file by method (I1) as given in emximp description
  in emx documentation. However, I have to admit I failed to create a
  suitable import file. The first step apparently is to remove the
  ordinals from the definition file and run "emximp -o newlib.imp newlib.def".
  However, if I now try to continue via "emximp newlib.imp", I just get
  "emximp: No output file selected in line 5 of newlib.imp".
If you want to avoid the need to find out all the details, it's possibly
easier to use "dllar" from pgcc/gcc-3.x packages, create a static lib and
let dllar create a DLL and import libraries for you. Then throw away the
DLL created by dllar and distribute the one with the correct ordinals
together with the import library created by dllar...

	Regards,
		Stefan
-- 
Micro$oft is not an answer. It is a question. The answer is 'no'.


**= Email   2 ==========================**

Date:  Wed, 31 Dec 2003 15:45:57 +0100 (CET)
From:  Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
Subject:  Re: lib vs. dll (was: Re:  Pine problem)

On Tue, 30 Dec 2003, Adrian Gschwend wrote:

> On Tue, 30 Dec 2003 14:35:14 -0500, Henry Sobotka wrote:
> 
> >This looks like a variant of yesterday's "zdll.lib" problem. Might be
> >code for Win32 adding [_]dll to library names.
> 
> can someone explain me the main difference between lib and dll? To be
> honest I don't really get the difference between that. On Unix systems
> I have the *.so files, what's the main difference to OS/2 DLL's and
> what should we use for UX2BS (and unixos2 in general)?

Actually, on Unix systems, you don't have just *.so files (roughly
equivalent to OS/2's DLLs, I never really remember the fine differences
as those are mostly irrelevant in practice), you also have *.a files
(equivalent to "normal" or "static" *.lib files).

I.e. DLLs contain functions that can be used by several programs and are
loaded dynamically at run time, libs contain the same code, but it's
linked into each program at link time, so each program contains its own
independent copy of the "common" code - which is "obviously" inefficient,
but see below.

What additionally complicates the situation is the fact, that linkers on
OS/2 are "too stupid" to directly handle DLLs the way Unix linkers handle
*.so files. Instead, the only format they know how to handle is the
format of *.lib files (and in the case of EMX of *.a files). So, in
addition to the "static" *.lib files described above, you also have the
"import" *.lib files which just tell the linker to put a reference to a
specific function of a specific DLL into the code. 

Now as to what one should use: "static" libs are "obviously" inefficient,
so the "obvious" answer is to use DLLs (and I'd prefer to follow XFree86's
convention of having something.DLL and "import" libs that are named
something.a and something.lib and "static" libs that are named
something_s.a and something_s.lib, if needed).

However the drawback is that memory that can be used for DLLs (or for
some specific part of each DLL, I don't really remember the details) is
rather limited and they always consume a rather large minimal amount of
space (unless you play some extra tricks?), so having many small DLLs is a
_bad_ idea as it causes you to run out of "DLL-memory", even if you have
plenty of RAM left - famous problem when piping something through a whole
series of those small helper programs from the various GNU utilities...

So, if you have some large library, that's used by only a few programs,
link it statically (i.e. no DLL). If you have a _very_ small library,
that's used by many programs still link it statically, as size increase
doesn't matter anyway, if it's not "too" small and used by 
"enough" programs, make it a DLL. 

     HTH,
	Stefan
-- 
Micro$oft is not an answer. It is a question. The answer is 'no'.


**= Email   3 ==========================**

Date:  Wed, 31 Dec 2003 16:42:06 +0000
From:  John Poltorak <jp at warpix.org>
Subject:  Re:  New ZLIB

On Wed, Dec 31, 2003 at 03:16:29PM +0100, Stefan Neis wrote:
> On Tue, 30 Dec 2003, Dave and Natalie wrote:
> 
> > >2. Even when switching to import by name, the OS/2 port must maintain
> > >   the old ordinals, which means no fully automated build is possible.
> > 
> > How exactly do you move over to import by name and keep the old ordinals?
> 
> Well, I had a look at EMX documentation, but I'm still guessing
> (hopefully, somebody will correct me, where I'm wrong):
> - Create the DLL "as usual" with a suitable ("backward
>   compatible") definition file defining ordinals.
> - Create the import file by method (I1) as given in emximp description
>   in emx documentation. However, I have to admit I failed to create a
>   suitable import file. The first step apparently is to remove the
>   ordinals from the definition file and run "emximp -o newlib.imp newlib.def".
>   However, if I now try to continue via "emximp newlib.imp", I just get
>   "emximp: No output file selected in line 5 of newlib.imp".
> If you want to avoid the need to find out all the details, it's possibly
> easier to use "dllar" from pgcc/gcc-3.x packages, create a static lib and
> let dllar create a DLL and import libraries for you. Then throw away the
> DLL created by dllar and distribute the one with the correct ordinals
> together with the import library created by dllar...


I would be interested in how you think the OS/2 Makefile included with 
ZLIB v1.1.4 should be changed.

I think it simply keeps getting included and has not been maintained for 
many years. The VER variable provides quite a hint about its age and I 
have no idea whether the comments included are accurate or not. I suspect 
not.

The problems I see are the hard coding of filenames such os2/z.def which 
doesn't exist any way. I would like prefix to be inherited from the 
environment along with SHELL

The *FLAGS probably need changing along with gcc's options and it would be 
nice to have a standard for library names. I don't much care for zdll.lib 
for SHAREDLIBIMP, but I guess if I can live with it if that if everyone 
else thinks it's acceptable, as long as the same naming convention is used 
in similar programs such as LIBPNG.


Here it is:-


# Makefile for zlib under OS/2 using GCC (PGCC)
# For conditions of distribution and use, see copyright notice in zlib.h 

# To compile and test, type:
#   cp Makefile.os2 ..
#   cd ..
#   make -f Makefile.os2 test

# This makefile will build a static library z.lib, a shared library
# z.dll and a import library zdll.lib. You can use either z.lib or
# zdll.lib by specifying either -lz or -lzdll on gcc's command line

CC=gcc -Zomf -s

CFLAGS=-O6 -Wall
#CFLAGS=-O -DMAX_WBITS=14 -DMAX_MEM_LEVEL=7
#CFLAGS=-g -DDEBUG
#CFLAGS=-O3 -Wall -Wwrite-strings -Wpointer-arith -Wconversion \
#           -Wstrict-prototypes -Wmissing-prototypes

#################### BUG WARNING: #####################
## infcodes.c hits a bug in pgcc-1.0, so you have to use either
## -O# where # <= 4 or one of (-fno-ommit-frame-pointer or -fno-force-mem)
## This bug is reportedly fixed in pgcc >1.0, but this was not tested
CFLAGS+=-fno-force-mem

LDFLAGS=-s -L. -lzdll -Zcrtdll
LDSHARED=$(CC) -s -Zomf -Zdll -Zcrtdll

VER=1.1.0
ZLIB=z.lib
SHAREDLIB=z.dll
SHAREDLIBIMP=zdll.lib
LIBS=$(ZLIB) $(SHAREDLIB) $(SHAREDLIBIMP)

AR=emxomfar cr
IMPLIB=emximp
RANLIB=echo
TAR=tar
SHELL=bash

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 infblock.o inftrees.o infcodes.o infutil.o 
inffast.o

TEST_OBJS = example.o minigzip.o

DISTFILES = README INDEX ChangeLog configure Make*[a-z0-9] *.[ch] 
descrip.mms \
  algorithm.txt zlib.3 msdos/Make*[a-z0-9] msdos/zlib.def msdos/zlib.rc \
  nt/Makefile.nt nt/zlib.dnt  contrib/README.contrib contrib/*.txt \
  contrib/asm386/*.asm contrib/asm386/*.c \
  contrib/asm386/*.bat contrib/asm386/zlibvc.d?? contrib/iostream/*.cpp \
  contrib/iostream/*.h  contrib/iostream2/*.h contrib/iostream2/*.cpp \
  contrib/untgz/Makefile contrib/untgz/*.c contrib/untgz/*.w32

all: example.exe minigzip.exe

test: all
	 at LD_LIBRARY_PATH=.:$(LD_LIBRARY_PATH) ; export LD_LIBRARY_PATH; \
	echo hello world | ./minigzip | ./minigzip -d || \
	  echo '		*** minigzip test FAILED ***' ; \
	if ./example; then \
	  echo '		*** zlib test OK ***'; \
	else \
	  echo '		*** zlib test FAILED ***'; \
	fi

$(ZLIB): $(OBJS)
	$(AR) $ at  $(OBJS)
	- at  ($(RANLIB) $ at  || true) >/dev/null 2>&1

$(SHAREDLIB): $(OBJS) os2/z.def
	$(LDSHARED) -o $ at  $^

$(SHAREDLIBIMP): os2/z.def
	$(IMPLIB) -o $ at  $^

example.exe: example.o $(LIBS)
	$(CC) $(CFLAGS) -o $ at  example.o $(LDFLAGS)

minigzip.exe: minigzip.o $(LIBS)
	$(CC) $(CFLAGS) -o $ at  minigzip.o $(LDFLAGS)

clean:
	rm -f *.o *~ example minigzip libz.a libz.so* foo.gz

distclean:	clean

zip:
	mv Makefile Makefile~; cp -p Makefile.in Makefile
	rm -f test.c ztest*.c
	v=`sed -n -e 's/\.//g' -e '/VERSION "/s/.*"\(.*\)".*/\1/p' < 
zlib.h`;\
	zip -ul9 zlib$$v $(DISTFILES)
	mv Makefile~ Makefile

dist:
	mv Makefile Makefile~; cp -p Makefile.in Makefile
	rm -f test.c ztest*.c
	d=zlib-`sed -n '/VERSION "/s/.*"\(.*\)".*/\1/p' < zlib.h`;\
	rm -f $$d.tar.gz; \
	if test ! -d ../$$d; then rm -f ../$$d; ln -s `pwd` ../$$d; fi; \
	files=""; \
	for f in $(DISTFILES); do files="$$files $$d/$$f"; done; \
	cd ..; \
	GZIP=-9 $(TAR) chofz $$d/$$d.tar.gz $$files; \
	if test ! -d $$d; then rm -f $$d; fi
	mv Makefile~ Makefile

tags:	
	etags *.[ch]

depend:
	makedepend -- $(CFLAGS) -- *.[ch]

# DO NOT DELETE THIS LINE -- make depend depends on it.

adler32.o: zlib.h zconf.h
compress.o: zlib.h zconf.h
crc32.o: 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
infblock.o: infblock.h inftrees.h infcodes.h infutil.h zutil.h zlib.h 
zconf.h
infcodes.o: zutil.h zlib.h zconf.h
infcodes.o: inftrees.h infblock.h infcodes.h infutil.h inffast.h
inffast.o: zutil.h zlib.h zconf.h inftrees.h
inffast.o: infblock.h infcodes.h infutil.h inffast.h
inflate.o: zutil.h zlib.h zconf.h infblock.h
inftrees.o: zutil.h zlib.h zconf.h inftrees.h
infutil.o: zutil.h zlib.h zconf.h infblock.h inftrees.h infcodes.h 
infutil.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  


 
> 	Regards,
> 		Stefan
> -- 
> Micro$oft is not an answer. It is a question. The answer is 'no'.
> 



-- 
John



**= Email   4 ==========================**

Date:  Wed, 31 Dec 2003 10:31:53 -0800
From:  "Dave and Natalie" <dave_yeo at mindlink.bc.ca>
Subject:  Re:  New ZLIB

On Wed, 31 Dec 2003 16:42:06 +0000, John Poltorak wrote:

>
>I would be interested in how you think the OS/2 Makefile included with 
>ZLIB v1.1.4 should be changed.

Seems most people are using Hung-Chi Chu's makefile and def files. At least thats what I've been using and a 
lot of XFree86 apps use.
Dave

New Email Address - please update your Address book
                      dave_yeo at paralynx.com


**= Email   5 ==========================**

Date:  Wed, 31 Dec 2003 18:58:42 +0000
From:  John Poltorak <jp at warpix.org>
Subject:  Re:  New ZLIB

On Wed, Dec 31, 2003 at 10:31:53AM -0800, Dave and Natalie wrote:
> On Wed, 31 Dec 2003 16:42:06 +0000, John Poltorak wrote:
> 
> >
> >I would be interested in how you think the OS/2 Makefile included with 
> >ZLIB v1.1.4 should be changed.
> 
> Seems most people are using Hung-Chi Chu's makefile and def files. 

Do you have a URL for that? I can't find it anywhere at the moment.

> At least thats what I've been using and a 
> lot of XFree86 apps use.

There is a port of v1.1.4 on Hobbes by Russell O'Connor.

Anyone using that version?


> Dave
> 
> New Email Address - please update your Address book
>                       dave_yeo at paralynx.com
> 


-- 
John



**= Email   6 ==========================**

Date:  Wed, 31 Dec 2003 13:02:08 -0800
From:  "Steven Levine" <steve53 at earthlink.net>
Subject:  Re: lib vs. dll (was: Re:  Pine problem)

In
<Pine.GSO.4.21.0312311518180.13055-100000 at cdc-ultra4.cdc.informatik.tu-darmstadt.de>,
on 12/31/03 
   at 03:45 PM, Stefan Neis <neis at cdc.informatik.tu-darmstadt.de> said:


>Actually, on Unix systems, you don't have just *.so files (roughly
>equivalent to OS/2's DLLs, I never really remember the fine differences
>as those are mostly irrelevant in practice),

Perhaps, the biggest difference is that .so files don't utilize the notion
of call by ordinal.  This is the real reason we need import libraries in
OS/2.  The DLLs often don't contain the information required to resolve
references by name.

>So, in
>addition to the "static" *.lib files described above, you also have the
>"import" *.lib files which just tell the linker to put a reference to a
>specific function of a specific DLL into the code. 

Yes, this can be confusing because while static and import libraries share
the same file extension, I'm pretty sure one can't use a static library in
place of an import library.

>However the drawback is that memory that can be used for DLLs (or for
>some specific part of each DLL, I don't really remember the details) is
>rather limited and they always consume a rather large minimal amount of
>space (unless you play some extra tricks?),

It's not so much limited, as shared.  Each loaded DLL reduces the
available private address space for every process regardless of whether or
not the process references the DLL.  Since the maximum private address
space is 488MB (in theory) this quickly becomes a problem with today's
hardware capable of running a large number of concurrent processes.

>famous problem when piping something through a
>whole series of those small helper programs from the various GNU
>utilities...

I forget the details, but I don't think this is a linear address space
issue.  ISTR it was related to file handles, but I my memory is dim on
this.

>So, if you have some large library, that's used by only a few programs,
>link it statically (i.e. no DLL). If you have a _very_ small library,
>that's used by many programs still link it statically, as size increase
>doesn't matter anyway, if it's not "too" small and used by  "enough"
>programs, make it a DLL. 

Agreed.  Unfortunately, there are quite a few apps that don't follow this
paradigm because despite their defects, DLLs are a handy way of segmenting
large applications.

Regards,

Steven


-- 
----------------------------------------------------------------------
"Steven Levine" <steve53 at earthlink.net>  MR2/ICE 2.41 #10183 Warp4/FP15/14.093c_W4
www.scoug.com irc.webbnet.info irc.fyrelizard.org #scoug (Wed 7pm PST)
----------------------------------------------------------------------


**= Email   7 ==========================**

Date:  Thu, 1 Jan 2004 12:01:43 +0000
From:  John Poltorak <jp at warpix.org>
Subject:   pthreads


I'm trying to find the latest port of pthreads for OS/2 and it appears 
that there are a number of seperate ports around. There's one on Hobbes, 
one on Netlabs and a new one included with XINE. 

It would be nice to get a definitive build.

Does anyone know the differences between them all and whether they are 
being actively maintained?


-- 
John