Date: Mon, 5 Jan 2004 00:04:05 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 283 ************************************************** Sunday 04 January 2004 Number 283 ************************************************** Subjects for today 1 Re: Innotek GCC 3.2.1 Beta3 status : Stefan Neis 2 Re: Innotek GCC 3.2.1 Beta3 status : Stefan Neis 3 Re: Pine problem : nps at zeta.org.au 4 Re: perl question : John Poltorak 5 Re: lib vs. dll (was: Re: Pine problem) : nps at zeta.org.au 6 GNU ed : John Poltorak 7 Re: New ZLIB : Andreas Buening 8 Re: perl question : Henry Sobotka 9 Re: GNU ed : Dave and Natalie" 10 Re: GNU ed : John Poltorak 1 Re: cannot find command processor in the path : Andreas Buening 11 Re: Pine problem : John Poltorak **= Email 1 ==========================** Date: Sat, 3 Jan 2004 16:53:38 +0100 (CET) From: Stefan Neis Subject: Re: Innotek GCC 3.2.1 Beta3 status On Sat, 3 Jan 2004, Yuri Dario wrote: > >I believe that is a known problem that Innotek has no intention of fixing. > > gdb requires some major work to support new formats. What's so new about the format? Has gdb changed so much "recently" (i.e. since emx-0.9d release) that the old patches by EM don't help any more or what's the problem? Any ideas? Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 2 ==========================** Date: Sat, 3 Jan 2004 16:51:19 +0100 (CET) From: Stefan Neis Subject: Re: Innotek GCC 3.2.1 Beta3 status On Fri, 2 Jan 2004, Dave Webster wrote: > Without -Zomf (ld and emxbind): > > Got much further here but still a notable problem. Static builds go fine all > the way through, and all my sample apps seem to work OK with static builds. > Release (optomized) DLL builds seem OK, too. Trouble comes with debug > (symbol table included) DLL builds. GCC322.DLL craps out with a c00000005 > fatal error trying to link the debug DLL and complains about a lack of stack > space available to even throw it's exception! It's relatively easy to increase stack space (just some linker flag), so this should be easy to fix in theory... > Only other issue is with a perplexing unresolved external in a secondary dll > build of an inlined class template function. Template instantiation tends to be a problem with gcc, especially on non-ELF platforms. However, the gcc versions I've been using until now (< 3.0) all tend to give you multiple definition errors rather than unresolved externals, unless you're using some special flags or #pragma statements. :-o > Another problem I have not really delved into yet, seems to be the inability > to load debug exes into gdb (using ld/emxbind build, no -Zomf). Is there a > compatible version of gdb I should be using? Name mangling has changed quite a bit, so it's not that surprising that the old gdb version doesn't work, unfortunately there isn't a new one and Innotek doesn't seem to be very interested in providing one. :-( Now let's see if your problems with OMF format can convince them that gdb might be important ... ;-) Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 3 ==========================** Date: Wed, 31 Dec 2003 09:30:23 +1100 (EST) From: nps at zeta.org.au Subject: Re: Pine problem Quoting John Poltorak : > Trying again, I don't get those problems. What I do get is problems in > the > Makefiles due to hardcoded paths which do not apply on my system along > with non-existant openssl libs even though I seem to have built openssl > successfully. Unfortunately the original Pine source codes #includes the OpenSSL headers as #include instead of #include so it is necessary to hard-code a -I in CFLAGS (see Henry's post), which I neglected to document when I wrote the compilation instructions. > I don't have a crypto_dll.lib. Should I get one built when building > openssl? I do have a crypto.dll. My OS/2 computer is in pieces at the moment so I can't check exactly what I did but if I remember rightly, crypto_dll.lib comes from the out_dll directory after building the DLL version of OpenSSL. I may have re-named it from crypto.lib so that I could have both the static and shared libraries installed at the same time (similarly ssl_dll.lib). Looks like I'll need to re-write the compilation instructions for the next release... Nicholas S. **= Email 4 ==========================** Date: Sun, 4 Jan 2004 00:04:34 +0000 From: John Poltorak Subject: Re: perl question On Sat, Jan 03, 2004 at 11:53:39AM +0000, Lyn St George wrote: > On Fri, 2 Jan 2004 11:14:43 +0000, John Poltorak wrote: > > >How do tell if an existing Perl was built with chown? > > One way is 'grep /path/to/perl5/5.8.x/os2 -i chown Config.pm', which > returns '' for me (and 'undef' for the chown variants). I thought there might be some option such as Perl -V which would show if chown was configured. I have '' in Config.pm but am not aware of any changes to the supplied source (for 5.8.0). > >> (the last is poached from the wind tree). Ilya Z does not agree with this as > >> it may clash with any multi-user method in future, but it does me for now. > > > >At this point in time would it be preferable to use chown? I could put > >the required changes into UX2BS so that it could default to HAS_CHOWN. > > Hmm ... Ilya was pretty adamant that this is "Bad Idea", though he was > talking about some theoretical change in the future. I doubt that Dave > S and I are the only ones who find that when chown is lacking from perl > then the consequence becomes a PITA. I personally would make it > the default, bearing in mind that it's so easy to rebuild perl with some > other implementation if need be. How do I test to see if I have chown defined in the built version of Perl ? If it isn't defined how do I patch the source? > - > Cheers > Lyn St George > +--------------------------------------------------------------------------------- > + http://www.zolotek.net .. eCommerce hosting, consulting > +---------------------------------------------------------------------------------- > -- John **= Email 5 ==========================** Date: Wed, 31 Dec 2003 09:52:41 +1100 (EST) From: nps at zeta.org.au Subject: Re: lib vs. dll (was: Re: Pine problem) Quoting Adrian Gschwend : > 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)? The .lib file is the "import library" used by the linker at link-time to locate the functions that will be called from the DLL at run time. It has no equivalent under Unix, so far as I know; Unix just uses the .so file for this purpose. The .dll is the "dynamically-linked library" that contains the executable code that will be called at run-time. It is equivalent to the .so file in Unix, but can't be used for linking at compile-time. So the role of .so is played by .lib at compile-time, and by .dll at run-time. Nicholas S. **= Email 6 ==========================** Date: Sun, 4 Jan 2004 00:28:38 +0000 From: John Poltorak Subject: GNU ed Is there any reason why GNU ed should not build and work straight out of the box on OS/2? I can build it OK, although I need to run EMXBIND to convert it to an OS/2 ..exe but I'm not sure it actually works. Is there a list of commands anywhere? I see it comes with a testsuite. Anyone know how to use it? I guess you just run make... but it doesn't work. -- John **= Email 7 ==========================** Date: Sat, 03 Jan 2004 15:52:12 +0100 From: Andreas Buening Subject: Re: New ZLIB Stefan Neis wrote: > > On Tue, 30 Dec 2003, Dave and Natalie wrote: > > 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): [snip] As far as I know the simplest way is to write a .def file which looks the following way: LIBRARY 'intl' INITINSTANCE TERMINSTANCE DESCRIPTION 'intl 0.11.5' DATA MULTIPLE NONSHARED STUB NONE EXPORTS gettext at 1 newname_for_gettext at 4 .... Bye, Andreas **= Email 8 ==========================** Date: Sat, 03 Jan 2004 19:50:15 -0500 From: Henry Sobotka Subject: Re: perl question John Poltorak wrote: > > I thought there might be some option such as Perl -V which would show if > chown was configured. > > I have '' in Config.pm but am not aware of any changes to the supplied > source (for 5.8.0). $Config{chown} refers to the file utility chown[.exe] and is normally '' (not just on OS/2). See the explanation of it in the pod section of Config.pm. $Config{d_chown} refers to the library function and sets #define HAS_CHOWN. > How do I test to see if I have chown defined in the built version of Perl ? [C:\temp]perl -e chown The chown function is unimplemented at -e line 1. If implemented, it'll probably croak about wrong number of args. > If it isn't defined how do I patch the source? The way Lyn patched his. I suspect the declaration of chown may not be necessary, because from a quick look at the HAS_CHOWN blocks, it looks like the library function isn't called; and if it were, you would have to link with a lib containing a dummy definition. h~ **= Email 9 ==========================** Date: Sun, 04 Jan 2004 00:23:40 -0800 From: "Dave and Natalie" Subject: Re: GNU ed On Sun, 4 Jan 2004 00:28:38 +0000, John Poltorak wrote: > > >Is there any reason why GNU ed should not build and work straight out of >the box on OS/2? > >I can build it OK, although I need to run EMXBIND to convert it to an OS/2 >.exe but I'm not sure it actually works. > >Is there a list of commands anywhere? > >I see it comes with a testsuite. Anyone know how to use it? I guess you >just run make... but it doesn't work. > Usually you run make check or make test. Also you might have to change cmp to diff in the makefile so the tests don't trip over LF vs CR/LF. This is just generic as I've never tried GNU ed Dave New Email Address - please update your Address book dave_yeo at paralynx.com **= Email 10 ==========================** Date: Sun, 4 Jan 2004 11:48:51 +0000 From: John Poltorak Subject: Re: GNU ed On Sun, Jan 04, 2004 at 12:23:40AM -0800, Dave and Natalie wrote: > On Sun, 4 Jan 2004 00:28:38 +0000, John Poltorak wrote: > > > > > > >Is there any reason why GNU ed should not build and work straight out of > >the box on OS/2? > > > >I can build it OK, although I need to run EMXBIND to convert it to an OS/2 > >.exe but I'm not sure it actually works. > > > >Is there a list of commands anywhere? > > > >I see it comes with a testsuite. Anyone know how to use it? I guess you > >just run make... but it doesn't work. > > > > Usually you run make check or make test. Also you might have to change cmp to diff in the makefile so the tests don't trip over LF vs CR/LF. > This is just generic as I've never tried GNU ed If you have UX2BS installed, could you try 'build ed' ? Maybe you could spot an obvious problem... > Dave > > New Email Address - please update your Address book > dave_yeo at paralynx.com > -- John **= Email 1 ==========================** Date: Sat, 03 Jan 2004 15:51:26 +0100 From: Andreas Buening Subject: Re: cannot find command processor in the path John Poltorak wrote: > > On Tue, Dec 30, 2003 at 02:59:44PM +0000, John Poltorak wrote: > > Why do I get an error msg about the command processor not being found in > > the path when it clearly is? > > This appears to be problem related to Make.... > > It does not occur when using an old version of Make (v3.76.1) but it's a > definite no-go with v3.79.1. Should I be using some additional envar such > as MAKESHELL or somesuch to get round the problem? I think I fixed such a bug some time ago. Can you try a newer version? Bye, Andreas **= Email 11 ==========================** Date: Sun, 4 Jan 2004 11:46:48 +0000 From: John Poltorak Subject: Re: Pine problem On Wed, Dec 31, 2003 at 09:30:23AM +1100, nps at zeta.org.au wrote: > Quoting John Poltorak : > > > Trying again, I don't get those problems. What I do get is problems in > > the > > Makefiles due to hardcoded paths which do not apply on my system along > > with non-existant openssl libs even though I seem to have built openssl > > successfully. > > Unfortunately the original Pine source codes #includes the OpenSSL headers > as #include instead of #include so it is necessary > to hard-code a -I in CFLAGS (see Henry's post), which I neglected to document > when I wrote the compilation instructions. I'm trying to stick as closely to a typical Unix distro as possible so that such changes should not be required. Where do the OpenSSL headers normally get installed under Linux? If it is in /usr/include/openssl then how does the compiler find them? > > I don't have a crypto_dll.lib. Should I get one built when building > > openssl? I do have a crypto.dll. > > My OS/2 computer is in pieces at the moment so I can't check exactly what > I did but if I remember rightly, crypto_dll.lib comes from the out_dll > directory after building the DLL version of OpenSSL. I may have re-named > it from crypto.lib so that I could have both the static and shared libraries > installed at the same time (similarly ssl_dll.lib). The only file I have under out_dll is crypto.dll. I don't have any *.lib files anywhere. This is with v0.9.7c. Maybe it didn't build properly... What should I expect to find there? > Nicholas S. -- John