Date: Wed, 19 Oct 2005 00:04:24 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 635 ************************************************** Tuesday 18 October 2005 Number 635 ************************************************** Subjects for today 1 Re: gdb for gcc 3.3.2 and 3.3.5? : Dave Yeo" 2 Re: OpenSSL v0.9.8 : Stefan.Neis at t-online.de" 3 Re: gdb for gcc 3.3.2 and 3.3.5? : Jon Saxton 4 Re: OpenSSL v0.9.8 : Stefan.Neis at t-online.de 5 Re: gdb for gcc 3.3.2 and 3.3.5? : Knut St. Osmundsen" 6 Re: gdb for gcc 3.3.2 and 3.3.5? : Stefan.Neis at t-online.de 7 Re: GNU Patch v2.54 : Andreas Buening 8 Re: GNU Patch v2.54 : John Poltorak 9 Re: gdb for gcc 3.3.2 and 3.3.5? : Jon Saxton 10 Re: gdb for gcc 3.3.2 and 3.3.5? : Jon Saxton 11 Re: OpenSSL v0.9.8 : John Poltorak 12 Re: gdb for gcc 3.3.2 and 3.3.5? : Jon Saxton 13 Creating DLLs : Paul Smedley 14 Re: Creating DLLs : Stefan.Neis at t-online.de" **= Email 1 ==========================** Date: Mon, 17 Oct 2005 08:07:04 -0700 (PDT) From: "Dave Yeo" Subject: Re: gdb for gcc 3.3.2 and 3.3.5? On Mon, 17 Oct 2005 08:46:03 -0400, Jon Saxton wrote: >Which of course leads to the question, what does one use for debugging >with the later versions of gcc? Surely it isn't necessary to learn all >that OMF stuff? (If I did, could I use idebug?) You have to compile to OMF then can use various debuggers. IIRC you can use idebug, I use http://hobbes.nmsu.edu/pub/os2/dev/util/sd386v50.zip Dave **= Email 2 ==========================** Date: Mon, 17 Oct 2005 17:56:56 +0200 From: "Stefan.Neis at t-online.de" Subject: Re: OpenSSL v0.9.8 Hi, > Did you apply that patch exactly as it appears? > > I got > > Hunk #1 FAILED at 68. > > but can't see any obvious reason why it should have failed. Might be an issue of spaces vs. tab or similar and I might just have been lucky - or maybe I did the change manually instead of applying a patch ... Regards, Stefan **= Email 3 ==========================** Date: Mon, 17 Oct 2005 12:01:20 -0400 From: Jon Saxton Subject: Re: gdb for gcc 3.3.2 and 3.3.5? Thanks, Dave for your reply. I had just come to the conclusion that the OMF route is mandatory. That raises some more issues because I cannot find any documentation on the omf switches. I looked in the GCC "docs" folder and tried various gcc --help options with no success. I have yet to look in the emx docs. That I'll do shortly. Can I still use gcc as a front end to the linker or do I have to change my makefiles to invoke ILINK? Dave Yeo wrote: >On Mon, 17 Oct 2005 08:46:03 -0400, Jon Saxton wrote: > > > >>Which of course leads to the question, what does one use for debugging >>with the later versions of gcc? Surely it isn't necessary to learn all >>that OMF stuff? (If I did, could I use idebug?) >> >> > >You have to compile to OMF then can use various debuggers. IIRC you can use idebug, I use http://hobbes.nmsu.edu/pub/os2/dev/util/sd386v50.zip >Dave > > > > > > **= Email 4 ==========================** Date: Mon, 17 Oct 2005 18:09:17 +0200 (CEST) From: Stefan.Neis at t-online.de Subject: Re: OpenSSL v0.9.8 John Poltorak schrieb: > > > but doesn't work for v0.9.8 BTW, did you realize that there meanwhile is openssl-0.9.8a? It seems to have the same problem, though, I'm going to write on or two mails to openssl-dev... Regards, Stefan **= Email 5 ==========================** Date: Mon, 17 Oct 2005 18:25:04 +0200 From: "Knut St. Osmundsen" Subject: Re: gdb for gcc 3.3.2 and 3.3.5? Jon Saxton wrote: > Thanks, Dave for your reply. > > I had just come to the conclusion that the OMF route is mandatory. That > raises some more issues because I cannot find any documentation on the > omf switches. I looked in the GCC "docs" folder and tried various gcc > --help options with no success. > > I have yet to look in the emx docs. That I'll do shortly. > > Can I still use gcc as a front end to the linker or do I have to change > my makefiles to invoke ILINK? gcc / g++ -Zomf will invoke ilink for you (using emxomfld). emxomfld will before invoking ilink to a prelink step in which it automatically converts any aout objects/libs to omf objects/libs. Thus it is only required to add -Zomf to the linking stage. If you cannot distiguish between the linking and the compiling, you must make sure you're using emxomfar and not ar as librarian. The ilink and emxomfld cannot make use of OMF objects in a library created with ar. Kind Regards, knut **= Email 6 ==========================** Date: Mon, 17 Oct 2005 18:29:28 +0200 (CEST) From: Stefan.Neis at t-online.de Subject: Re: gdb for gcc 3.3.2 and 3.3.5? Jon Saxton schrieb: > That raises some more issues because I cannot find any > documentation on the omf switches. Essentially, it's just requiring to use "gcc -Zomf" instead of "gcc" and "emxomfar" instead of "ar". > Can I still use gcc as a front end to the linker or do I > have to change > my makefiles to invoke ILINK? It's definitely preferable to use "gcc" instead of trying to call the linker directly (but _do_ get the "ilink" version pointed to at t he page of the mozilla people explaining what tools to use to compile mozilla for OS/2, using e.g. link386 really isn't workable). Hm, thinking about it, I don't remember any more how gcc or gccenv.cmd is detecting which linker you're using, so maybe there's some tweaking involved there as well. Regards, Stefan **= Email 7 ==========================** Date: Mon, 17 Oct 2005 20:21:09 +0200 From: Andreas Buening Subject: Re: GNU Patch v2.54 John Poltorak wrote: > > Has anyone managed to build GNU Patch v2.54? I have it running here. I think I've built it long time ago. Bye, Andreas **= Email 8 ==========================** Date: Mon, 17 Oct 2005 19:47:16 +0100 From: John Poltorak Subject: Re: GNU Patch v2.54 On Mon, Oct 17, 2005 at 08:21:09PM +0200, Andreas Buening wrote: > John Poltorak wrote: > > > > Has anyone managed to build GNU Patch v2.54? > > I have it running here. I think I've built it long time ago. I managed to build it from source once, but I think it needs some patches. Any chance of uploading your port somewhere? > > Bye, > Andreas -- John **= Email 9 ==========================** Date: Mon, 17 Oct 2005 15:26:13 -0400 From: Jon Saxton Subject: Re: gdb for gcc 3.3.2 and 3.3.5? Knut: Thanks also for your input. I have made much progress but I am one small step from having it work properly. I had to tweak a lot of my environment settings and my dmake configuration files to run emxomfar instead of ar, to let me see ilink.exe, idebug.exe and the DLLs and data files that those programs need. I set emxomf_linker and exmomfld_type even though the default is set for VAC++ 3.6.5 which is what I have installed. I rebuilt my own (static) libraries by compiling with -Zomf and using emxomfar to assemble a .lib file. I thought that I had the libraries in the right format so I put -Xlibrary -Zno-autoconv in the gcc linker invocation command to stop automatic conversion of my libraries from a.out format to omf format. The current stumbling block is a message which pops out of the link ... wealkd:: ..\lib\os2\simpl.lib: error: Invalid library format or read error emxomfld: weak prelinker failed. (rc=-1) I have the impression that emxomfld really prefers a.out format. :-) I'll try rebuilding my libraries the old way but it would be really annoying to have to compile with -Zomf for most code but without -Zomf for stuff that is going into a library. I expect that isn't going to be necessary and that it is probably just a matter of understanding this stuff much better. Knut St. Osmundsen wrote: > > > Jon Saxton wrote: > >> Thanks, Dave for your reply. >> >> I had just come to the conclusion that the OMF route is mandatory. >> That raises some more issues because I cannot find any documentation >> on the omf switches. I looked in the GCC "docs" folder and tried >> various gcc --help options with no success. >> >> I have yet to look in the emx docs. That I'll do shortly. >> >> Can I still use gcc as a front end to the linker or do I have to >> change my makefiles to invoke ILINK? > > > gcc / g++ -Zomf will invoke ilink for you (using emxomfld). > > emxomfld will before invoking ilink to a prelink step in which it > automatically converts any aout objects/libs to omf objects/libs. Thus > it is only required to add -Zomf to the linking stage. > > If you cannot distiguish between the linking and the compiling, you > must make sure you're using emxomfar and not ar as librarian. The > ilink and emxomfld cannot make use of OMF objects in a library created > with ar. > > Kind Regards, > knut > > > > -- Jon Saxton Shopkeeper, Numismatist-in-training Developer of cross-platform software for UNIX, OS/2 and Windows U.S. Agent for Triton Technologies International Ltd http://www.triton.vg/ **= Email 10 ==========================** Date: Mon, 17 Oct 2005 15:27:36 -0400 From: Jon Saxton Subject: Re: gdb for gcc 3.3.2 and 3.3.5? Knut: Thanks also for your input. I have made much progress but I am one small step from having it work properly. I had to tweak a lot of my environment settings and my dmake configuration files to run emxomfar instead of ar, to let me see ilink.exe, idebug.exe and the DLLs and data files that those programs need. I set emxomf_linker and exmomfld_type even though the default is set for VAC++ 3.6.5 which is what I have installed. I rebuilt my own (static) libraries by compiling with -Zomf and using emxomfar to assemble a .lib file. I thought that I had the libraries in the right format so I put -Xlibrary -Zno-autoconv in the gcc linker invocation command to stop automatic conversion of my libraries from a.out format to omf format. The current stumbling block is a message which pops out of the link ... wealkd:: ..\lib\os2\simpl.lib: error: Invalid library format or read error emxomfld: weak prelinker failed. (rc=-1) I have the impression that emxomfld really prefers a.out format. :-) I'll try rebuilding my libraries the old way but it would be really annoying to have to compile with -Zomf for most code but without -Zomf for stuff that is going into a library. I expect that isn't going to be necessary and that it is probably just a matter of understanding this stuff much better. Knut St. Osmundsen wrote: > > > Jon Saxton wrote: > >> Thanks, Dave for your reply. >> >> I had just come to the conclusion that the OMF route is mandatory. >> That raises some more issues because I cannot find any documentation >> on the omf switches. I looked in the GCC "docs" folder and tried >> various gcc --help options with no success. >> >> I have yet to look in the emx docs. That I'll do shortly. >> >> Can I still use gcc as a front end to the linker or do I have to >> change my makefiles to invoke ILINK? > > > gcc / g++ -Zomf will invoke ilink for you (using emxomfld). > > emxomfld will before invoking ilink to a prelink step in which it > automatically converts any aout objects/libs to omf objects/libs. Thus > it is only required to add -Zomf to the linking stage. > > If you cannot distiguish between the linking and the compiling, you > must make sure you're using emxomfar and not ar as librarian. The > ilink and emxomfld cannot make use of OMF objects in a library created > with ar. > > Kind Regards, > knut > > > > **= Email 11 ==========================** Date: Mon, 17 Oct 2005 20:47:35 +0100 From: John Poltorak Subject: Re: OpenSSL v0.9.8 On Mon, Oct 17, 2005 at 05:56:56PM +0200, Stefan.Neis at t-online.de wrote: > Hi, > > > Did you apply that patch exactly as it appears? > > > > I got > > > > Hunk #1 FAILED at 68. > > > > but can't see any obvious reason why it should have failed. > > Might be an issue of spaces vs. tab or similar and I might just > have been lucky - or maybe I did the change manually instead > of applying a patch ... Yes, it was stupid of me not to notice that. Having applied that patch, I'm still getting one of the same errors that I got originally gcc -Ioutinc -Itmp_dll -DL_ENDIAN -O3 -fomit-frame-pointer -m486 -Zmtd .... .... tmp_dll/e_nuron.obj tmp_dll/e_sureware.obj tmp_dll/e_ubsec.obj -lsocket os2/CRYPTO.def LINK386 : error L2022: pqueue_print (alias pqueue_print) : export undefined There was 1 error detected make: *** [out_dll/crypto.dll] Error 1 There is also an error when running os2\os2-emx.cmd - unable to rename Makefile but I can't tell which Makefile this refers to. > Regards, > Stefan > > -- John **= Email 12 ==========================** Date: Mon, 17 Oct 2005 17:55:49 -0400 From: Jon Saxton Subject: Re: gdb for gcc 3.3.2 and 3.3.5? So close! I rebuilt the libraries as .a files in a.out format. Now gcc -Zomf -o gives various errors depending on the specific command line. Sometimes it just spaces up about ten lines and exits without generating an exe or any message. Other times I get LNK1081 errors (out of space for ) or "No space for NB04" whatever that might be. Very frustrating. I may end up moving the code to a UNIX system and debugging there. Might be easier. Jon Saxton wrote: > Knut: > > Thanks also for your input. I have made much progress but I am one > small step from having it work properly. > > I had to tweak a lot of my environment settings and my dmake > configuration files to run emxomfar instead of ar, to let me see > ilink.exe, idebug.exe and the DLLs and data files that those programs > need. I set emxomf_linker and exmomfld_type even though the default is > set for VAC++ 3.6.5 which is what I have installed. > > I rebuilt my own (static) libraries by compiling with -Zomf and using > emxomfar to assemble a .lib file. I thought that I had the libraries in > the right format so I put -Xlibrary -Zno-autoconv in the gcc linker > invocation command to stop automatic conversion of my libraries from > a.out format to omf format. > > The current stumbling block is a message which pops out of the link ... > > wealkd:: ..\lib\os2\simpl.lib: error: Invalid library format or read > error > emxomfld: weak prelinker failed. (rc=-1) > > I have the impression that emxomfld really prefers a.out format. :-) > I'll try rebuilding my libraries the old way but it would be really > annoying to have to compile with -Zomf for most code but without -Zomf > for stuff that is going into a library. I expect that isn't going to be > necessary and that it is probably just a matter of understanding this > stuff much better. > > > > Knut St. Osmundsen wrote: > >> >> >> Jon Saxton wrote: >> >>> Thanks, Dave for your reply. >>> >>> I had just come to the conclusion that the OMF route is mandatory. >>> That raises some more issues because I cannot find any documentation >>> on the omf switches. I looked in the GCC "docs" folder and tried >>> various gcc --help options with no success. >>> >>> I have yet to look in the emx docs. That I'll do shortly. >>> >>> Can I still use gcc as a front end to the linker or do I have to >>> change my makefiles to invoke ILINK? >> >> >> >> gcc / g++ -Zomf will invoke ilink for you (using emxomfld). >> >> emxomfld will before invoking ilink to a prelink step in which it >> automatically converts any aout objects/libs to omf objects/libs. >> Thus it is only required to add -Zomf to the linking stage. >> >> If you cannot distiguish between the linking and the compiling, you >> must make sure you're using emxomfar and not ar as librarian. The >> ilink and emxomfld cannot make use of OMF objects in a library >> created with ar. >> >> Kind Regards, >> knut >> >> >> >> > > > > > **= Email 13 ==========================** Date: Tue, 18 Oct 2005 19:43:31 +0930 From: Paul Smedley Subject: Creating DLLs Hi All, Based on a user request, I just built Image Magick v6.2.5 With the default settings, it statically links against magick.a This is fine except that magick.a is over 2mb in size, and there are ten different programs that use this library, with the result being each of the 10 programs is 1.8mb even lxlited. I'd like to create a magick.dll and link against that. Can anyone tell me step by step how to do this or point me to some kind of documentation on how to do this? Cheers, Paul. **= Email 14 ==========================** Date: Tue, 18 Oct 2005 14:15:30 +0200 From: "Stefan.Neis at t-online.de" Subject: Re: Creating DLLs Hi, > I'd like to create a magick.dll and link against that. > > Can anyone tell me step by step how to do this or point me to some > kind of documentation on how to do this? Once you have magick.a, just run "dllar -libflags INITINSTANCE -libflags TERMINSTANCE -o magick.dll magick.a" That should - rename magick.a to magick_s.a (the static library). - create magick.dll - create magick.a as import library. Whatever you then link against that new magick.a will use the dll. [ Note that for C++ code involving templates, the symbol and function names _can_ be quite large, so the import library (and executables buil with it) sometimes are not that much smaller than the static version... ] Regards, Stefan