From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sat, 29 Jun 2002 04:29:02 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 257 ************************************************** Friday 28 June 2002 Number 257 ************************************************** Subjects for today 1 libtool : John Poltorak 2 Re: Rebuilding \emx\lib : John Poltorak 3 libiconv : John Poltorak 4 Gettext : John Poltorak 5 Re: Perl 5.73 and perl212F.dll : Michel SUCH" 6 Re: Perl 5.73 and perl212F.dll : Stefan Neis 7 Re: Perl 5.73 and perl212F.dll : Henry Sobotka 8 Re: Perl 5.73 and perl212F.dll : Andrew Belov" **= Email 1 ==========================** Date: Sat, 29 Jun 2002 10:31:28 +0100 From: John Poltorak Subject: libtool Has anyone managed to install the latest libtool? What did you need to do? How can you tell whether it is installed correctly? I tried building the latest version straight from GNU and have libtool and libtoolize shell scripts in c:\usr\local\bin which is on the path when I make builds, and there is also a c:\usr\local\share\libtool dir with assorted files, but when I try building an app which looks for libtool, it can't find it, so it looks as though the install may have missed out some step. -- John **= Email 2 ==========================** Date: Sat, 29 Jun 2002 10:51:49 +0100 From: John Poltorak Subject: Re: Rebuilding \emx\lib On Fri, Jun 28, 2002 at 06:40:06PM -0400, Henry Sobotka wrote: > John Poltorak wrote: > > Is there a way to specify a target directory? > > > > I would like the new libs to appear in \usr\lib if posible, and assume the > > original libs must be available to build new libs... > > Only insofar as gcc needs the emx runtime.DLLs. C_LIBRARY_PATH is > irrelevant to linkage, though might be used to determine where to > install the new libraries. It does overwrite itself; IIRC that's > mentioned in the build doc, which might also describe how to set the > target directory. Otherwise, a look through the makefiles and/or batch > files should turn up how it's handled. It looks to me as though there is no facility for building libs in any location other than the original location. I have tried moving the original \emx\lib to \usr\lib and setting the variable to point there, so that the new libs get created in \emx\lib and while most do seem to get built OK, a number of builds fail with errors which do occur when they are built over the top of the originals. Having said that, I've just noticed that \emx\src\lib\makefile has the line:- L=\emx\lib\ so I guess if I change that to L=\usr\lib\, maybe that will override it... ...or should L be the same as C_LIBRARY_PATH? It isn't described anywhere. > h~ -- John **= Email 3 ==========================** Date: Sat, 29 Jun 2002 10:59:16 +0100 From: John Poltorak Subject: libiconv If anyone has managed to build and install libiconv, can you give me some instructions and as well as a list of prerequisites such as software, headers, libs etc? -- John **= Email 4 ==========================** Date: Sat, 29 Jun 2002 11:06:01 +0100 From: John Poltorak Subject: Gettext If anyone has succeeded in building gettext v0.11.2 especially in 'masochist' mode, I'd like to know exactly what you did because I always fail miserably when trying to do this, and I have tried many many times. There seem to be soooooo many dependencies to getting this right and gettext seems to be such a key part to so many GNU apps that it is essential to have it installed. -- John **= Email 5 ==========================** Date: Sat, 29 Jun 2002 15:17:15 +0100 (CET) From: "Michel SUCH" Subject: Re: Perl 5.73 and perl212F.dll Well, Here is what I get when it fails: PERL212F.DLL 0001:000bb5eb P1=00000001 P2=00000000 P3=XXXXXXXX P4=XXXXXXXX EAX=00000000 EBX=040cb024 ECX=11f982b0 EDX=0432c650 ESI=042f711c EDI=03f6fb28 DS=0053 DSACC=f0f3 DSLIM=ffffffff ES=0053 ESACC=f0f3 ESLIM=ffffffff FS=150b FSACC=00f3 FSLIM=00000030 GS=0000 GSACC=**** GSLIM=******** CS:EIP=005b:1e08b5eb CSACC=f0df CSLIM=ffffffff SS:ESP=0053:03f6f9a8 SSACC=f0f3 SSLIM=ffffffff EBP=ffffffff FLG=00012212 If it can help... On Thu, 27 Jun 2002 14:01:22 -0400, Henry Sobotka wrote: >Michel SUCH wrote: >> >> Sorry, it is not perl 5.73 but 5.72! >> >> On Thu, 27 Jun 2002 19:05:12 +0100 (CET), Michel SUCH wrote: >> >> >Sometimes I have this dll crashing when running perl (for example when >> >running ./configure for automake 1.6.2. >> >Is this a known problem and is there a fix. >> >Note: after this crash, the configure script goes on and completes, but i >> >am not quite sure the automake I build is clean. > >Are there any crash details in config.log and/or popuplog.os2? > >h~ > > ---------------------------- Michel SUCH TEAM OS/2 FRANCE ICQ # 51654489 **= Email 6 ==========================** Date: Sat, 29 Jun 2002 16:42:56 +0200 (CEST) From: Stefan Neis Subject: Re: Perl 5.73 and perl212F.dll > Here is what I get when it fails: > > PERL212F.DLL 0001:000bb5eb > P1=00000001 P2=00000000 P3=XXXXXXXX P4=XXXXXXXX > EAX=00000000 EBX=040cb024 ECX=11f982b0 EDX=0432c650 (snipp) > > If it can help... Anybody cares to explain to a nosy individual how one extracts useful information from this kind of dump? I know that core files are handled by gdb (and how), but which program is extracting something useful from those register dumps and how much information do you really get? Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 7 ==========================** Date: Sat, 29 Jun 2002 21:57:05 -0400 From: Henry Sobotka Subject: Re: Perl 5.73 and perl212F.dll Stefan Neis wrote: > > > Here is what I get when it fails: > > > > PERL212F.DLL 0001:000bb5eb > > P1=00000001 P2=00000000 P3=XXXXXXXX P4=XXXXXXXX > > EAX=00000000 EBX=040cb024 ECX=11f982b0 EDX=0432c650 > (snipp) > > > > If it can help... > > Anybody cares to explain to a nosy individual how one extracts useful > information from this kind of dump? I know that core files are handled > by gdb (and how), but which program is extracting something useful from > those register dumps and how much information do you really get? The second item on the first line is the crash address. With that you can check the DLL map to see what's there, set a nearby breakpoint in a debug build and try to reproduce the failure in an OMF-literate debugger. You could also step through a noncrashing call of the function concerned, see what instructions are setting the registers, compare the crash with the noncrash registers, and try to think your way through the bug from there. Basically, it tells you exactly where the crash occurred and the state of the machine at that instant; not a bad place to start, especially given that users aren't willing to pay for house calls, and teleporting is only in its infancy. h~ **= Email 8 ==========================** Date: Sat, 29 Jun 2002 22:27:22 +0300 (MSK) From: "Andrew Belov" Subject: Re: Perl 5.73 and perl212F.dll On Sat, 29 Jun 2002 16:42:56 +0200 (CEST), Stefan Neis wrote: >> Here is what I get when it fails: >> >> PERL212F.DLL 0001:000bb5eb >> P1=00000001 P2=00000000 P3=XXXXXXXX P4=XXXXXXXX >> EAX=00000000 EBX=040cb024 ECX=11f982b0 EDX=0432c650 >(snipp) >> >> If it can help... > >Anybody cares to explain to a nosy individual how one extracts useful >information from this kind of dump? I know that core files are handled >by gdb (and how), but which program is extracting something useful from >those register dumps and how much information do you really get? Using a tool like HIEW, it is possible to find out the exact location of error - 0001:00bb5eb means "object 1, offset 0xbb5eb". By disassembling the corresponding location in code, one may see what registers were involved in the failed operation - things like accessing a null pointer become obvious then. Even without any profound knowledge of 80x86 assembler, this dump is still readable, provided there is a map file close at hand - the name of failed procedure can be discovered from the list of public symbols sorted by address.