Date: Thu, 22 Jan 2004 00:07:06 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [Ux2bs_Archive] No. 262 ************************************************** Wednesday 21 January 2004 Number 262 ************************************************** Subjects for today 1 Re: Any new UX2BS testers? : knut st. osmundsen" 2 Re: Any new UX2BS testers? : knut st. osmundsen" 3 Re: Any new UX2BS testers? : John Poltorak **= Email 1 ==========================** Date: Tue, 20 Jan 2004 23:48:20 +0100 From: "knut st. osmundsen" Subject: Re: Any new UX2BS testers? Andreas Buening wrote: > Andreas Buening wrote: > > [a far too long mail] > > If this doesn't convince you, the following might change your mind: > > Assume, Knut had implemented his 6+2 naming scheme into libtool and > is now prepared to do the real world test: compiling GNU gettext. ;-) > ;-) > > Since 0.11 gettext doesn't install only libintl but also two internal > helper libraries: libgettextlib and libgettextsrc which are used by > the gettext tools only, no other program in the world knows about > them. Therefore, the new libtool would install intl0B.dll and also > gettex0B.dll and (Oops!) gettex0B.dll. You would need at least 8 > significant chars to distinguish both dlls: gettextl.dll and > gettexts.dll. Since the libtool logic doesn't provide any knowledge > which library gets installed from another source directory of the > source tree, it's not possible to implement an automatic mechanism to > avoid this kind of naming conflict within a package. Ouch! > > What you can do, is to implement an OS/2-specific magic, e.g. an env. > var. like > EMX_LIBTOOL_DLLNAMES="s/gettextsrc/gtsrc0B/;s/gettextlib/gtlib0B/" > which is processed somewhere deep in the libtool voodoo code. I've allready implemented a _name_ wrapper, only I've called it LT_OS2_DLL_MAPPING, only it's applied before release or version numbers are appended. As for your question about 2.57 so is that easily represented by three characters. No big deal. > This also means that it's impossible to get a useful installation of > gettext without any kind of intelligence at the other end of the > command line. ;-) So we need some kind of maintainer who resolves the > naming conflicts manually. > > Once we've arrived at this stage, why should we implement some code > for dll name replacements by using sed _and_ some code to implement > some magic naming scheme. Why not use the first one for both? Because that means extra effort for whomever is running ./configure. So, it's better to enforce a naming scheem and have tools for fixing conflicts when the occure, like here. It's of course not a 100% proof scheme, but it's better than the current non existing scheme. > Even better: How can libtool know whether we want a .lib or a .a > library? I've implemented a mechanism that uses .a if gcc produces .o > files, and .lib for .obj files. But gcc 3.x produces only .o files by > default. grepping $CFLAGS is insufficient to distinguish between > a.out and omf since the user might have used CC="gcc options" or > CPPFLAGS="-Zomf". The more you think about libtool, the more > difficult the problem becomes. :-( I though I'd already boasted about the new auto conversion of objects and libraries feature of emxomfld. You build objects with the default format of GCC (a.out), and if you wanna link with -Zomf then emxomfld will temporarily convert the input files during the linking. Kind Regards, knut _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 2 ==========================** Date: Tue, 20 Jan 2004 23:46:51 +0100 From: "knut st. osmundsen" Subject: Re: Any new UX2BS testers? John Poltorak wrote: > On Mon, Jan 19, 2004 at 10:32:43PM +0100, Andreas Buening wrote: > >>Stefan.Neis at t-online.de wrote: >> >>E.g., gettext is now reaching version 0.14. The announcement says 0.14 >>will provide support for C# (new dll GNU.gettext.dll), a new feature for >>Farsi (Persian) has been added, and the language code for Norwegian has >>changed in 2003. Great. I doubt that this justifies any significant code >>change for intl.dll compared to 0.13. Oh, new version already. Those GNU guys are indeed hasty. I'll take a look at it once 0.13 is working. > I'm still struggling to create an INTL library which will work when > building an old version of GREP! UX2BS is at something of an impasse until > I get this fixed. > > As far as I am concerned I see GETTEXT as an essential requirement for > UnixOS/2 and would prefer INTL.DLL to always be based on the most recently > available GETTEXT. Of course, it's inclusion in any UnixOS/2 distro would > require some integration testing with every app which used INTL.DLL John, I'll make gettext work before next GCC release and bundle it with it somehow. Currently my GCC buildenvironment is broken because of conflicting INTL.DLL versions, so there will be no GCC release until I've built a working gettext. Kind Regards, knut PS. I need a faster shell! configure, libtool and all those shell scripts are way to slow on OS/2. Anyone seen any open sourced shell which preferes threads to fork(), or at least fancy spawn()? (I wished I had time to rewrite ash or something to do this, but it's a bit of work and I don't have any spare time.) _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 3 ==========================** Date: Wed, 21 Jan 2004 09:25:11 +0000 From: John Poltorak Subject: Re: Any new UX2BS testers? On Tue, Jan 20, 2004 at 11:46:51PM +0100, knut st. osmundsen wrote: > John Poltorak wrote: > >>E.g., gettext is now reaching version 0.14. The announcement says 0.14 > >>will provide support for C# (new dll GNU.gettext.dll), a new feature for > >>Farsi (Persian) has been added, and the language code for Norwegian has > >>changed in 2003. Great. I doubt that this justifies any significant code > >>change for intl.dll compared to 0.13. > Oh, new version already. Those GNU guys are indeed hasty. > I'll take a look at it once 0.13 is working. > > > I'm still struggling to create an INTL library which will work when > > building an old version of GREP! UX2BS is at something of an impasse until > > I get this fixed. > > > > As far as I am concerned I see GETTEXT as an essential requirement for > > UnixOS/2 and would prefer INTL.DLL to always be based on the most recently > > available GETTEXT. Of course, it's inclusion in any UnixOS/2 distro would > > require some integration testing with every app which used INTL.DLL > > John, I'll make gettext work before next GCC release and bundle it with > it somehow. Currently my GCC buildenvironment is broken because of > conflicting INTL.DLL versions, so there will be no GCC release until > I've built a working gettext. As it is GETTEXT _appears_ to build properly with UX2BS, but fails to provide an INTL lib which works correctly when building other apps which need it. I can't figure out why. I wondered if you have ever tried setting up UX2BS... It would be pointless you getting GETTEXT built correctly if I am unable to reproduce your results. UX2BS ensures a consistent build environment so it should be easy to reproduce anyone elses build experience, and it can be used in parallel with an existing production build environment because it runs in its own shell and does not interfere with anything else. > Kind Regards, > knut > > PS. I need a faster shell! Are you using PDKSH? > configure, libtool and all those shell > scripts are way to slow on OS/2. Anyone seen any open sourced shell > which preferes threads to fork(), or at least fancy spawn()? > > (I wished I had time to rewrite ash or something to do this, but it's a > bit of work and I don't have any spare time.) -- John _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs