Date: Fri, 27 Feb 2004 00:04:05 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 299 ************************************************** Thursday 26 February 2004 Number 299 ************************************************** Subjects for today 1 Innotek gcc update : Dave Webster 2 Re: Innotek gcc update : Yuri Dario" 3 Re: Innotek gcc update : Stefan Neis 4 Re: GCC 3.2.2 Beta 4 : Stefan Neis 5 Re: Innotek gcc update : Stefan Neis 6 RE: Innotek gcc update : Dave Webster 7 RE: Innotek gcc update : Dave and Natalie" 8 Re: GCC 3.2.2 Beta 4 : Henry Sobotka **= Email 1 ==========================** Date: Wed, 25 Feb 2004 08:50:28 -0600 From: Dave Webster Subject: Innotek gcc update This is for wxWindows. configure is now successful in building a Makefile. I did alter some -Z compiler switches in configure.in to get it build one with reasonable compiler options. Also Innotek uses -lstdc++ not lstdcxx and it also needs lsupc++. Resulting makefile still doesn't work, but it is close. There is something wrong with the ./bk-deps script that get built. It confuses the OS/2 command interpreter, so I had to manually edit the makefile to not use it to get any compiles to work at all. Also following the instructions in the OS/2 install.txt the make want to build a DLL as once it gets past the built-in support libs (zlib, jpeg, etc..) it issues -DWXMAKINGDLL_BASE for some odd reason. I had to edit dlimport.h as well as WXEXPORT was being defined. The line: # elif (!(defined(__VISAGECPP__) && (__IBMCPP__ < 400 || __IBMC__ < 400 ))) basically holds true for anything not VA. Surprised emx was working (emx must define _Export). Anyway just deleting that and using an ELSE got me past that one. But the thing still wants to build a shared lib for some reason using the default instructions. Guess I'll have to try --disable-shared. So still working on getting an Innotek build of wxOS2 2.5.1. And this is ld, not -Zomf. -Zomf cannot be used when building a Makefile from configure because configure is a Unix util that expects its little testers to a.out binaries not OMF binaries. Probably going to have look at using this Bakefile, XML based Makefile generation ala the Visual C or msw route. But I know even less about Bakefiles than configure and autoconf..... PS Stefan, you can remove all the VisualAge stuff if you want to. I will no longer be supporting that compiler as it is badly out of date and no longer supported or sold. **= Email 2 ==========================** Date: Wed, 25 Feb 2004 16:32:44 +0100 (CET) From: "Yuri Dario" Subject: Re: Innotek gcc update Hi Dave, >So still working on getting an Innotek build of wxOS2 2.5.1. And this is >ld, not -Zomf. -Zomf cannot be used when building a Makefile from configure >because configure is a Unix util that expects its little testers to a.out >binaries not OMF binaries. you can run configure without -Zomf: after end, open config.status and change CFLAGS and other macros. Then run 'sh -c config.status' and your makefiles will be updated. I'm using this for -Zlinker, because quotes are not handled by scripts. Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.os2power.com/yuri * http://www.teamos2.it */ **= Email 3 ==========================** Date: Wed, 25 Feb 2004 17:20:29 +0100 (CET) From: Stefan Neis Subject: Re: Innotek gcc update On Wed, 25 Feb 2004, Dave Webster wrote: > This is for wxWindows. configure is now successful in building a Makefile. > I did alter some -Z compiler switches in configure.in to get it build one > with reasonable compiler options. Also Innotek uses -lstdc++ not lstdcxx > and it also needs lsupc++. I already have a compiler check to use either -lstdcpp (gcc-2.8.1) or -lstdcxx (gcc-3.2.1) in configure, extending it to autodetect gcc-3.2.2 is going to be easy. > Resulting makefile still doesn't work, but it is > close. There is something wrong with the ./bk-deps script that get built. > It confuses the OS/2 command interpreter, Sure. It expects a Unix-like SHELL. Try getting e.g. pdksh, install it, and "set MAKESHELL=sh" (see also docs/os2/install.txt ;-) ) and everything should just work ... It might actually be a good idea to rewrite bk-deps for cmd.exe. I'll give that a try and see if it affects the build speed, _if_ I can find some time for this... > so I had to manually edit the > makefile to not use it to get any compiles to work at all. That way, you're going to not get dependencies, so if anything changes you typically will have to "make clean && make" and recompile everything. > Also following the instructions in the OS/2 install.txt the make want to > build a DLL as once it gets past the built-in support libs (zlib, jpeg, > etc..) it issues -DWXMAKINGDLL_BASE for some odd reason. > > I had to edit dlimport.h as well as WXEXPORT was being defined. The line: > > # elif (!(defined(__VISAGECPP__) && (__IBMCPP__ < 400 || __IBMC__ < 400 > ))) > > basically holds true for anything not VA. Surprised emx was working (emx > must define _Export). Strange, that works automatically for me. Does gcc-3.2.2 actually define __EMX__ at all? > reason using the default instructions. Guess I'll have to try > --disable-shared. Very strange, configure is currently supposed to do that automatically on OS/2. > So still working on getting an Innotek build of wxOS2 2.5.1. I hope to be able to have a look at trying this as well ... ;-) > And this is ld, not -Zomf. > -Zomf cannot be used when building a Makefile from configure > because configure is a Unix util that expects its little testers to a.out > binaries not OMF binaries. IIRC, there is some easy fix for that, let's see if somebody on one of the lists remembers ... > Probably going to have look at using this > Bakefile, XML based Makefile generation ala the Visual C or msw route. But > I know even less about Bakefiles than configure and autoconf..... Actually, Bakefile is currently generating Makefile.in and some other files related to autoconf/configure anyway ... > PS Stefan, you can remove all the VisualAge stuff if you want to. I will no > longer be supporting that compiler as it is badly out of date and no longer > supported or sold. I think, wxWindows should not yet have exceeded the level of C++ support offered by VAC++, so I tend to leave it in for some more time, since somebody might be interested in trying his luck in using it ... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 4 ==========================** Date: Wed, 25 Feb 2004 17:27:04 +0100 (CET) From: Stefan Neis Subject: Re: GCC 3.2.2 Beta 4 On Wed, 25 Feb 2004, Knut St. Osmundsen wrote: > It's not that I'm unfriendly against gdb, it's only that the day have 24 > hours, the week 7 days, and so on.. Yes, I know that feeling ... ;-) > I would rather spend time on going for GCC 3.3.3, getting binutils ld > working, implement fork(), and so on, instead of porint and supporting > yet another debugger which I'm not going to use anyway (I must use the > HLL debuggers in order to test HLL debuginfo). I tend to agree with your reasoning ... > If anyone cares enough for gdb the sources are there, I'm willing to > answer questions, I accept patches (unless they are crap/bad/ugly). The only problem is that the day has 24 hours only ... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 5 ==========================** Date: Wed, 25 Feb 2004 17:20:29 +0100 (CET) From: Stefan Neis Subject: Re: Innotek gcc update On Wed, 25 Feb 2004, Dave Webster wrote: > This is for wxWindows. configure is now successful in building a Makefile. > I did alter some -Z compiler switches in configure.in to get it build one > with reasonable compiler options. Also Innotek uses -lstdc++ not lstdcxx > and it also needs lsupc++. I already have a compiler check to use either -lstdcpp (gcc-2.8.1) or -lstdcxx (gcc-3.2.1) in configure, extending it to autodetect gcc-3.2.2 is going to be easy. > Resulting makefile still doesn't work, but it is > close. There is something wrong with the ./bk-deps script that get built. > It confuses the OS/2 command interpreter, Sure. It expects a Unix-like SHELL. Try getting e.g. pdksh, install it, and "set MAKESHELL=sh" (see also docs/os2/install.txt ;-) ) and everything should just work ... It might actually be a good idea to rewrite bk-deps for cmd.exe. I'll give that a try and see if it affects the build speed, _if_ I can find some time for this... > so I had to manually edit the > makefile to not use it to get any compiles to work at all. That way, you're going to not get dependencies, so if anything changes you typically will have to "make clean && make" and recompile everything. > Also following the instructions in the OS/2 install.txt the make want to > build a DLL as once it gets past the built-in support libs (zlib, jpeg, > etc..) it issues -DWXMAKINGDLL_BASE for some odd reason. > > I had to edit dlimport.h as well as WXEXPORT was being defined. The line: > > # elif (!(defined(__VISAGECPP__) && (__IBMCPP__ < 400 || __IBMC__ < 400 > ))) > > basically holds true for anything not VA. Surprised emx was working (emx > must define _Export). Strange, that works automatically for me. Does gcc-3.2.2 actually define __EMX__ at all? > reason using the default instructions. Guess I'll have to try > --disable-shared. Very strange, configure is currently supposed to do that automatically on OS/2. > So still working on getting an Innotek build of wxOS2 2.5.1. I hope to be able to have a look at trying this as well ... ;-) > And this is ld, not -Zomf. > -Zomf cannot be used when building a Makefile from configure > because configure is a Unix util that expects its little testers to a.out > binaries not OMF binaries. IIRC, there is some easy fix for that, let's see if somebody on one of the lists remembers ... > Probably going to have look at using this > Bakefile, XML based Makefile generation ala the Visual C or msw route. But > I know even less about Bakefiles than configure and autoconf..... Actually, Bakefile is currently generating Makefile.in and some other files related to autoconf/configure anyway ... > PS Stefan, you can remove all the VisualAge stuff if you want to. I will no > longer be supporting that compiler as it is badly out of date and no longer > supported or sold. I think, wxWindows should not yet have exceeded the level of C++ support offered by VAC++, so I tend to leave it in for some more time, since somebody might be interested in trying his luck in using it ... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 6 ==========================** Date: Wed, 25 Feb 2004 11:55:48 -0600 From: Dave Webster Subject: RE: Innotek gcc update -----Original Message----- From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] Sent: Wednesday, February 25, 2004 10:20 AM To: os2-unix at mail.warpix.org Cc: wxOS2-pm (E-mail); WxWinDevel (E-mail); Unix-OS2 (E-mail 2) Subject: Re: Innotek gcc update On Wed, 25 Feb 2004, Dave Webster wrote: I already have a compiler check to use either -lstdcpp (gcc-2.8.1) or -lstdcxx (gcc-3.2.1) in configure, extending it to autodetect gcc-3.2.2 is going to be easy. Well, that good news, I'm not a configure guy at all, so I'm not entirely sure I'd know what to change at all. I just edited some obvious spots, manually. Sure. It expects a Unix-like SHELL. Try getting e.g. pdksh, install it, and "set MAKESHELL=sh" (see also docs/os2/install.txt ;-) ) and everything should just work ... It might actually be a good idea to rewrite bk-deps for cmd.exe. I'll give that a try and see if it affects the build speed, _if_ I can find some time for this... Well, I've currently got all the unix-like utils from the Mozilla project, which is almost all of them (shells like ash and bash and couple of others, but not that one). As for bk-deps, once again, I wouldn't know where to start. That way, you're going to not get dependencies, so if anything changes you typically will have to "make clean && make" and recompile everything. Yea, but it at least compiles something instead of giving an error about not being able to find the command interpreter. > Also following the instructions in the OS/2 install.txt the make want to > build a DLL as once it gets past the built-in support libs (zlib, jpeg, > etc..) it issues -DWXMAKINGDLL_BASE for some odd reason. > > I had to edit dlimport.h as well as WXEXPORT was being defined. The line: > > # elif (!(defined(__VISAGECPP__) && (__IBMCPP__ < 400 || __IBMC__ < 400 > ))) > > basically holds true for anything not VA. Surprised emx was working (emx > must define _Export). Strange, that works automatically for me. Does gcc-3.2.2 actually define __EMX__ at all? This one stems from Innotek not defining __EMX__ so configure just thinks it is regular Linux gcc, I guess. Because the default is for the gtk Makefile to build a shared lib, which is what I'm getting. And you don't see the error because you are building with WXMAKINGDLL_ set. > reason using the default instructions. Guess I'll have to try > --disable-shared. Very strange, configure is currently supposed to do that automatically on OS/2. Probably something to do with not getting the __EMX__ or some other OS/2 specific thing. Probably thinks it is just Linux/Gtk gcc 3.2.2... > So still working on getting an Innotek build of wxOS2 2.5.1. I hope to be able to have a look at trying this as well ... ;-) IIRC, there is some easy fix for that, let's see if somebody on one of the lists remembers ... Yea, somebody else posted about editing config.status and rerunning that. I think, wxWindows should not yet have exceeded the level of C++ support offered by VAC++, so I tend to leave it in for some more time, since somebody might be interested in trying his luck in using it ... OK, but the list of files is outdated. The 2.4.x branch is OK under VA, but 2.5.x will not be. Besides, with Innotek I can now set USE_STD_IOSTREAMS to on and other STL/ISO stuff and it should work . **= Email 7 ==========================** Date: Wed, 25 Feb 2004 15:20:21 -0800 From: "Dave and Natalie" Subject: RE: Innotek gcc update On Wed, 25 Feb 2004 11:55:48 -0600, Dave Webster wrote: > As for bk-deps, once again, I wouldn't know where to >start. A good start might be to copy it to bk-deps.cmd and add extproc sh as the first line. sh can be the full path, eg f:\usr\bin\sh.exe or f:\usr\bin\ash.exe. Cmd.exe will then load sh to run the script Dave **= Email 8 ==========================** Date: Wed, 25 Feb 2004 20:10:13 -0500 From: Henry Sobotka Subject: Re: GCC 3.2.2 Beta 4 Thanks, Knut, now I understand the shared+DLL. A problem with emxomfar. Fed foo.o and bar/foo.o, where foo.o contains foo() and bar/foo.o contains bar(), emxomfar croaks with "Symbol multiply defined: foo!" (referring to foo.o, not foo()). ar has no such problem, but then feeding foobar.a to emxomf results in the same failure. Is that fixable? A while back I tried finding where in the emxomfar srcs the module name gets processed, but to no avail. h~ -- Free software, free minds.