Date: Mon, 5 Jan 2004 00:07:07 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [Ux2bs_Archive] No. 254 ************************************************** Sunday 04 January 2004 Number 254 ************************************************** Subjects for today 1 Re: Any new UX2BS testers? : Andreas Buening 2 Re: Re: lib vs. dll (was: Re: [UnixOS2] Pine problem) : Andreas Buening 3 Re: Any new UX2BS testers? : Andreas Buening 4 Re: Any new UX2BS testers? : Andreas Buening 5 Re: Any new UX2BS testers? : Andreas Buening 6 Re: Re: lib vs. dll (was: Re: [UnixOS2] Pine problem) : Stefan.Neis at t-online.de 7 Re: pthreads : Dave and Natalie" 8 Re: pthreads : John Poltorak 1 Re: Any new UX2BS testers? : knut st. osmundsen" 2 Re: Any new UX2BS testers? : John Poltorak 3 Re: Any new UX2BS testers? : Dave and Natalie" 4 Re: Any new UX2BS testers? : Andreas Buening 8 Re: Any new UX2BS testers? : Dave and Natalie" **= Email 1 ==========================** Date: Sat, 03 Jan 2004 15:51:04 +0100 From: Andreas Buening Subject: Re: Any new UX2BS testers? Dave and Natalie wrote: [snip] > Libtool works quite well for producing static libs but I've only had > one DLL successfully built by libtool, libiconv 1.8. Usually libtool > complains about not being able to build DLLs on OS/2 due to OS/2 not > supporting unresolved symbols. I don't really know if OS/2 does support > unresolved symbols. Which version of libtool prints this message? I have vague (and very bad) memories of the -u flag of emxexp which gives you also the names of otherwise uninitialized symbols and could be the reason for those "unresolved" symbols. These are global variables that are defined but not initialized. E.g. a definition like 'int bar;'. In fact, at program start 'bar' is initialized with 0 but 'int bar;' is different from 'int bar = 0;' because the first variable (int bar;) will be put into the BSS segment. the second one (int bar = 0;) into the DATA segment. This has very weird consequences: As most of you won't know the C programming language supports a technique called 'Common Blocks' in other languages. This means you can define int bar; in one source file, and double bar; in another source file, and you can link both files together (!), and the symbol 'bar' will refer to the same address in both files (!!!). Nevertheless, if both declarations of 'bar' have different size as is the case above, then the result is undefined (but I'm not sure about that). Things become difficult if your shared library foo.so defines a variable "int bar;", and your program does the same. In this case both variables refer to the same address. But this is not possible for OS/2 dlls (or maybe it's not possible for link386, I'm not sure about this) because all symbols in a DLL must be resolved at link time (of the DLL). But "int bar" is resolved at the link time of the program. So it's not possible to use this trick when compiling OS/2 programs with dynamic linking. (and the glibc and also gettext make use of this trick). However it's very easy to fix the code: You can use "int bar;" in your library and you create the foo.def file with "emxexp -u". The only thing: You have to use "extern int bar;" in your program instead of just "int bar;". I hope my explanation was understandable. ;-) Bye, Andreas _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 2 ==========================** Date: Sat, 03 Jan 2004 15:51:19 +0100 From: Andreas Buening Subject: Re: Re: lib vs. dll (was: Re: [UnixOS2] Pine problem) Stefan Neis wrote: [snip] > 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. Wasn't this just a problem with that buggy ld version which produced DLLs with 32 MB stack size? Bye, Andreas _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 3 ==========================** Date: Sat, 03 Jan 2004 15:51:31 +0100 From: Andreas Buening Subject: Re: Any new UX2BS testers? knut st. osmundsen wrote: [snip] > Nope. Still a few driveletter issues in autoconf 2.59. Also for the > gcc/binutils build systems (where we have a selfcontained CVS tree), > 'make install' doesn't do the trick. So, I've patched both > autoconf/automake to use UNIXROOT to find any locations and to not have > hardcoded interpreter paths. (I had to do this once for autoconf 2.13 > and what ever automake I'm currently using for gcc/binutils.) Please, could you explain more detailed when autoconf/automake should use UNIXROOT and whether you've already submitted any patches? > >> Maybe libtool does too, although I've never figured out how to use > >> it... > Yeah, libtool is a funny piece of shell script. I've allready patched > the in-tree libtool stuff for binutils/gcc, so when encountering it in > gettext I figured it were time to take a look at the latest libtool > version(s) and get it done once. (libtool is an interesting tool, only a > pain in the a$$ to configure and run on OS/2 - wish someone could do an > fast bash/ash/csh/*sh port with builtin sed one day. What's your current state with libtool? [snip] > The goal is to get make it produce static lib and .dll with import lib. Some time ago I fixed libtool 1.4.3 so that it produces static, import and shared libraries but this won't help you if you need 1.5 or higher. Bye, Andreas _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 4 ==========================** Date: Sat, 03 Jan 2004 15:52:01 +0100 From: Andreas Buening Subject: Re: Any new UX2BS testers? knut st. osmundsen wrote: > > John Poltorak wrote: > > On Thu, Jan 01, 2004 at 06:27:50PM +0100, knut st. osmundsen wrote: > > > > > >>> Does Andreas Buening know about these problems? I thought he had > >>> manage to get all outstanding OS/2 issues sorted out. And are > >>> your changes going to be incorporated into the mainstream > >>> version? If not then it will mean a constant catch up process in > >>> v2.60 and every subsequent release. > >> > >> I'm sort of surprised about some of these issues myself as there is > >> another platform with driveletters called Windows around. One or > >> two of these problems were, IIRC, related to objdir!=srcdir. I > >> don't mind playing catchup with the the original if the changes are > >> as few as these. I'm not sure they'll welcome some of my UNIXROOT > >> patches, nor I'm a sure about if they like Andreas/my abs. path > >> check extensions. > I just saw Andreas had some views on extensions, I must say I share his > view with _s.a for static and .a for dlls. But, I've got a little > suprise for him, next gcc release will be able to link with .dll's just > like one can link with .so's in linux. (This will ease my hacking on the > innotek gcc specific libtools port.) > For instance: > gcc -o foo.exe foo.c /usr/lib/bar.dll Uh-oh but this is still an optional feature? With dlls and libtool you have the problem that dll names are restricted to 8 chars while import libraries can be arbitrarily long. So gettextlib.lib is okay, but gettextlib.dll is not. My current implementation has been to strip the dll name down to 8 chars :-( while the static and import libs have the full name. [snip] Bye, Andreas _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 5 ==========================** Date: Sat, 03 Jan 2004 15:51:51 +0100 From: Andreas Buening Subject: Re: Any new UX2BS testers? Stefan.Neis at t-online.de wrote: [snip] > > Do we have anything like a naming convention for static and import libs? > > XFree86 uses something.a/lib (import) and something_s.a/lib (static). > "dllar" seems to do the same thing. > libz's makefile apparently generates zdll.a/lib (import) and > z.a/lib (static). But no automatic tool can keep track of these package dependent naming conventions. I had the idea to use directories /usr/libstatic, /usr/libimport or similar if we explicitely want to link some program statically or dynamically (and /usr/lib for the default, whatever it might be). > > And how do I recognise which is which? > > Import libs are smaller. For the files in .a format, you can use "nm" In my opinion the simplest way is to run emxexp on this library. If it contains any symbols, it's a static library. If it seems to be empty, it's an import library. :-) Bye, Andreas _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 6 ==========================** Date: Sat, 3 Jan 2004 17:26:50 +0100 From: Stefan.Neis at t-online.de Subject: Re: Re: lib vs. dll (was: Re: [UnixOS2] Pine problem) Hi, > Wasn't this just a problem with that buggy ld version which produced > DLLs with 32 MB stack size? Well, that was at least part of the problem. I don't really know, if it's actually all the problem or if there are other issues in favour of avoiding "unnecessary" DLLs... Regards, Stefan _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 7 ==========================** Date: Sat, 03 Jan 2004 12:15:30 -0800 From: "Dave and Natalie" Subject: Re: pthreads On Sat, 03 Jan 2004 11:36:54 +0100 (CET), Adrian Gschwend wrote: >full ACK. CVS exists so I'm happy to give write access to other people. >Is the xine pthreads library based on the work of Antony? Most of the files are the same as Antony's. Dave New Email Address - please update your Address book dave_yeo at paralynx.com _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 8 ==========================** Date: Sat, 3 Jan 2004 21:16:37 +0000 From: John Poltorak Subject: Re: pthreads On Sat, Jan 03, 2004 at 11:36:54AM +0100, Adrian Gschwend wrote: > On Thu, 1 Jan 2004 17:34:50 +0000, John Poltorak wrote: > > >Does a snapshot get produced periodically? > > no, I thought about doing that, probably I should :-) > > >I prefer to use a specific version if possible. > > Hmm is anyone actually working on that code? Knut? Because I doubt > Antony still does, he switched to Linux IIRC. The archives on Netlabs are suffixed bjs (Brian Smith?) although the most recent update is almost four years old. BTW they appear to be corrupted. Can you check them out? > >I've also found another version of pthreads being maintained by the porter > >of XINE for OS/2. > > >It seems that whenever there are multiple maintainers for any port, we > >will have conflicts sooner or later. It would be nice to get these two > >versions converged into one. > > full ACK. CVS exists so I'm happy to give write access to other people. > Is the xine pthreads library based on the work of Antony? Yes, but they may be based on those from Hobbes and might not include any of the updates which appear on those at Netlabs, so it would be useful to try and amalgamate the changes if possible. > cu > > Adrian > > > > -- > Adrian Gschwend > at netlabs.org > > ktk [a t] netlabs.org > ------- > Free Software for OS/2 and eCS > http://www.netlabs.org -- John _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 1 ==========================** Date: Sun, 04 Jan 2004 00:44:12 +0100 From: "knut st. osmundsen" Subject: Re: Any new UX2BS testers? Andreas Buening wrote: > knut st. osmundsen wrote: > >> John Poltorak wrote: >> >>> On Thu, Jan 01, 2004 at 06:27:50PM +0100, knut st. osmundsen >>> wrote: >>> >>> >>> >>>>> Does Andreas Buening know about these problems? I thought he >>>>> had manage to get all outstanding OS/2 issues sorted out. >>>>> And are your changes going to be incorporated into the >>>>> mainstream version? If not then it will mean a constant catch >>>>> up process in v2.60 and every subsequent release. >>>> >>>> I'm sort of surprised about some of these issues myself as >>>> there is another platform with driveletters called Windows >>>> around. One or two of these problems were, IIRC, related to >>>> objdir!=srcdir. I don't mind playing catchup with the the >>>> original if the changes are as few as these. I'm not sure >>>> they'll welcome some of my UNIXROOT patches, nor I'm a sure >>>> about if they like Andreas/my abs. path check extensions. >> >> I just saw Andreas had some views on extensions, I must say I share >> his view with _s.a for static and .a for dlls. But, I've got a >> little suprise for him, next gcc release will be able to link with >> .dll's just like one can link with .so's in linux. (This will ease >> my hacking on the innotek gcc specific libtools port.) For >> instance: gcc -o foo.exe foo.c /usr/lib/bar.dll > > > Uh-oh but this is still an optional feature? With dlls and libtool > you have the problem that dll names are restricted to 8 chars while > import libraries can be arbitrarily long. So gettextlib.lib is okay, > but gettextlib.dll is not. My current implementation has been to > strip the dll name down to 8 chars :-( while the static and import > libs have the full name. Yeah, that 8 char limit sucks. (It's there for performance reasons IIRC, because that prevented the kernel for having to allocate variable length modulename strings. Think it was done during the infamous 4MB tuning of OS/2 2.x. My Win32k driver can enable longer DLL names if anyone cares - I'm not using that driver any longer.) As for libtool porting, I of course make sure the dll name is no more than 8 chars long (incuding any release number stuff). The first two numbers in the release string (if present) is appended with no dots and not in decimal but 36 digit numbers, 0-9A-Z, to save precious space. (Any sugestions about ways to encode a couple of numbers in a more condense way is welcome.) The porting is going slowly (but I've got both DLLs and libs now) since I encountered some trouble telling libtool about import libraries. One would think the Win32 guys had tought libtool that concept years ago, but not. Looking at the effort, I soon decieded to change the toolchain to support a more UNIX/GNU way with libraries. Since OS/2 support shared objects (DLLs) the default should be for the linker to link with the shared libraries whenever present. There are linker/gcc options for changing this behaviour, -static (-Bstatic, -dn, -non_shared), causing only static libraries to be included in the link. I'm setting the following rules for library names and search order now for the next gcc/binutils/libc release: - shared mode (default): 1. libfoo_dll.a 2. foo_dll.a 3. libfoo.a 4. foo.a 5. foo.dll 6. libfoo_s.a 7. foo_s.a - static mode: 1. libfoo_s.a 2. foo_s.a 3. libfoo.a 4. foo.a The -Zomf linker will check for .lib before .a, it will also automatically convert from aout to omf (using tmporary storage). (The searching for 'lib' prefixed libs have been in since early 3.2.2 development.) I'm currently working on the toolchain changes not libtool. Kind Regards, knut PS. The libtool port is intended for GCC 3.2.2 and later because that's what I need it for. _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 2 ==========================** Date: Sun, 4 Jan 2004 00:10:26 +0000 From: John Poltorak Subject: Re: Any new UX2BS testers? On Sat, Jan 03, 2004 at 03:51:31PM +0100, Andreas Buening wrote: > Some time ago I fixed libtool 1.4.3 so that it produces static, import > and shared libraries but this won't help you if you need 1.5 or higher. Is this the most recent version of libtool available for OS/2? Do you have a URL for it? > > Bye, > Andreas -- John _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 3 ==========================** Date: Sat, 03 Jan 2004 20:53:17 -0800 From: "Dave and Natalie" Subject: Re: Any new UX2BS testers? On Sat, 03 Jan 2004 15:51:04 +0100, Andreas Buening wrote: >Dave and Natalie wrote: > >[snip] > >> Libtool works quite well for producing static libs but I've only had >> one DLL successfully built by libtool, libiconv 1.8. Usually libtool >> complains about not being able to build DLLs on OS/2 due to OS/2 not >> supporting unresolved symbols. I don't really know if OS/2 does support >> unresolved symbols. > >Which version of libtool prints this message? Every version Including yours X:\usr\src\blackbox>ash libtool --version ltmain.sh (GNU libtool) 1.4.3 (1.922.2.111 2002/10/23 02:54:36) Dave ps thanx for the other info, need to meditate on it New Email Address - please update your Address book dave_yeo at paralynx.com _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 4 ==========================** Date: Sun, 04 Jan 2004 12:16:01 +0100 From: Andreas Buening Subject: Re: Any new UX2BS testers? John Poltorak wrote: > > On Sat, Jan 03, 2004 at 03:51:31PM +0100, Andreas Buening wrote: > > > Some time ago I fixed libtool 1.4.3 so that it produces static, import > > and shared libraries but this won't help you if you need 1.5 or higher. > > Is this the most recent version of libtool available for OS/2? > > Do you have a URL for it? http://unix.os2site.com/sw/pub/source/libtool/libtool-1_4_3.zip Bye, Andreas _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 8 ==========================** Date: Sat, 03 Jan 2004 15:50:19 -0800 From: "Dave and Natalie" Subject: Re: Any new UX2BS testers? On Sun, 04 Jan 2004 00:44:12 +0100, knut st. osmundsen wrote: >- static mode: > 1. libfoo_s.a > 2. foo_s.a > 3. libfoo.a > 4. foo.a > >The -Zomf linker will check for .lib before .a, it will also >automatically convert from aout to omf (using tmporary storage). >(The searching for 'lib' prefixed libs have been in since early 3.2.2 >development.) > >I'm currently working on the toolchain changes not libtool. Noticed that gcc3.2.2 picked up socket.a (emx) before libsocket.a. Had to change -lsocket to -llibsocket Dave New Email Address - please update your Address book dave_yeo at paralynx.com _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs