Date: Thu, 2 Jun 2005 00:05:18 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 559 ************************************************** Wednesday 01 June 2005 Number 559 ************************************************** Subjects for today 1 Cleaning up my dev environment (aka want to build mod_jk) : Steven Levine" 2 Re: Cleaning up my dev environment (aka want to build mod_jk) : Dave Yeo" 3 Re: Cleaning up my dev environment (aka want to build mod_jk) : Steven Levine" **= Email 1 ==========================** Date: Tue, 31 May 2005 15:21:09 -0700 From: "Steven Levine" Subject: Cleaning up my dev environment (aka want to build mod_jk) Hi, I'd like to try porting mod_jk, but my dev environment is not quite up to the task and I'd like to discuss how to get a more robust and easy to maintain setup with minimum fuss. I've been lurking on the list so I think I have a reasonable idea of the status of os2ports and ux2bs. The mod_jk configure was not sufficiently OS/2 aware and could not find gcc, so I ran it through Ilya's convert_configure.pl. This allowed configure to find gcc, but configure then failed attempting to check the validity of the compiler output. I did not spend too much time investigating why. I decided it would be better to run autoconf and get an OS/2 aware configure script. Of course, mod_jk wanted a newer autoconf than I current have installed, so I decided that the time has probably come to get the gcc/emx toolchain cleaned and upgraded. The two basic prerequistes are minimum distruption of what I currently have installed and in use. On the OS/2 side this includes VAC 3.08, VAC 3.65, Watcom 1.3, gcc 2.8.1, gcc 3.2.1, gcc3.2.2 and gcc3.3.5. As expected, I have limited time to work on this, but I'm make time once I'm convinced myself that the results will be better than what I have now. I've considered installing ux2bs, although this does not really seem to be the way to go for my current needs. There is the dedicated volume issue which I can live with, but my analysis so far seems to indicate ux2bs may not install sufficiently current versions of what I really need. Are my conclusions way off base? As is typical, my problems are of mostly of my own making. Over the years many packages that now install by default into unixos2_fhs style directories have landed in the \emx tree because it was there. This is something I had planned to resolve as time permits. Directories such as /bin, /lib and /usr/* are already in place, but the files that should be in these directories are mostly still in then /emx tree. If I reorganize and populate the directories, is this going to get me close to being able to take the distro of a package such as autconf from hobbes or os2ports and do: sh ./configure make install and have a working tool? Thanks, Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.67 #10183 Warp4.something/14.100c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 2 ==========================** Date: Tue, 31 May 2005 21:13:07 -0800 From: "Dave Yeo" Subject: Re: Cleaning up my dev environment (aka want to build mod_jk) --_=_=_=IMA.BOUNDARY.IHDSPV138764=_=_=_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, 31 May 2005 15:21:09 -0700, Steven Levine wrote: >Hi, > >I'd like to try porting mod_jk, but my dev environment is not quite up to >the task and I'd like to discuss how to get a more robust and easy to >maintain setup with minimum fuss. > >I've been lurking on the list so I think I have a reasonable idea of the >status of os2ports and ux2bs. > >The mod_jk configure was not sufficiently OS/2 aware and could not find >gcc, so I ran it through Ilya's convert_configure.pl. This allowed >configure to find gcc, but configure then failed attempting to check the >validity of the compiler output. I did not spend too much time >investigating why. I decided it would be better to run autoconf and get >an OS/2 aware configure script. Of course, mod_jk wanted a newer autoconf >than I current have installed, so I decided that the time has probably >come to get the gcc/emx toolchain cleaned and upgraded. > >The two basic prerequistes are minimum distruption of what I currently >have installed and in use. On the OS/2 side this includes VAC 3.08, VAC >3.65, Watcom 1.3, gcc 2.8.1, gcc 3.2.1, gcc3.2.2 and gcc3.3.5. As >expected, I have limited time to work on this, but I'm make time once I'm >convinced myself that the results will be better than what I have now. > >I've considered installing ux2bs, although this does not really seem to be >the way to go for my current needs. There is the dedicated volume issue >which I can live with, but my analysis so far seems to indicate ux2bs may >not install sufficiently current versions of what I really need. Are my >conclusions way off base? > >As is typical, my problems are of mostly of my own making. Over the years >many packages that now install by default into unixos2_fhs style >directories have landed in the \emx tree because it was there. This is >something I had planned to resolve as time permits. Directories such as >/bin, /lib and /usr/* are already in place, but the files that should be >in these directories are mostly still in then /emx tree. If I reorganize >and populate the directories, is this going to get me close to being able >to take the distro of a package such as autconf from hobbes or os2ports >and do: > > sh ./configure > make install > >and have a working tool? > >Thanks, > >Steven > Hi Steven, there are most likely as many approaches to setting up a unixy build enviroment as there are developers. I too still have quite a few utilities still installed in /emx as well as /usr and as long as they are on the %PATH% configure usually finds them. At that /emx is on e:/, /usr on f: and I: and I build on f:/, g:/ and i:/ (also X:/ which is a TVFS volume.) For some things it is better to have /usr on the same partition as where you're building, eg often configure finds /usr/X11R6 all on its own but only if on the same partition. This is handy as traditional EMX apps and libs are installed on f: and Innotek apps and libs on I:, good to keep seperate as a lot of the libs are not compatible. To get configure to work here I use a config.site which configure will find if it is in $PREFIX/share or defined by %CONFIG_SITE%. $PREFIX usually defaults to /usr/local. In config.site I have things like CC=gcc.exe PERL=perl.exe etc so configure finds them ok. (CC=gcc PERL=perl are most likely good enough nowadays) Also CFLAGS, LDFLAGS etc. Unluckily this is setup for a.out builds which Knut doesn't like and doesn't put to much effort into supporting them. Often it is as simple to add a couple of -Zomf to the makefile to change to OMF though there can be problems with libs, once again Innotek handles this better. Also this system only works for GCC versions newer then 2.8.1 as I use -Zexe to force an executable and often configure tests for foo instead of foo.exe and 2.8.1 outputs a 0 byte foo. Newer GCCs output a small foo that executes foo.exe. 2.95.3 is quite stable for this. 3.2.1 has a major problem in being linked against its own iconv.dll causing conflict if you have gnu iconv.dll installed. 3.0.3 is what Frank uses to build XFree86 and is the most compatible for XFree86 libs though I find it has problems with some C++. Of course the Innotek GCCs seem the best now as long as you're not linking to older libs such as XFree86 (and Apache?). I'll attach my config.site which could be a beginning for you though I really should clean it up when I have time . Also the newer the autoconf the more likely it will work on OS/2 due to fixes done for Windows eg now sees the right path seperator, understands backslashes and what .exe means. With my setup I can often do sh configure --prefix=/usr make (perhaps add a couple of includes etc and rerun make) make install (this is with packages DLed from gnu.org, sourceforge etc) Though it is a good idea to start with configure --help I've even had a couple of DLLs get built this way though usually static libs are built. Anyways look at my config.site for guidence, don't worry to much about things in /emx unless configure complains, just have /usr ahead of /emx in PATH etc and install newer versions in /usr Dave ps don't forget C_INCLUDE_PATH etc --_=_=_=IMA.BOUNDARY.IHDSPV138764=_=_=_ Content-Type: application/octet-stream; name="config.site" Content-Transfer-Encoding: base64 IyFzaA0KIyBjb25maWcuc2l0ZQ0KIyAgICAgICAgICBzZXQgIENPTkZJR19TSVRFPXg6L2Zvby9j b25maWcuc2l0ZQ0KDQpDT05GSUdfU0hFTEw9c2gNCmV4cG9ydCBDT05GSUdfU0hFTEwNCg0KIyBP cHRpbWl6YXRpb24gKEdOVSBtYWtlIDMuNzQgY2Fubm90IGJlIGxvYWRlZCA6LSgpOg0KIyBlbXhs b2FkIC1tIDMwIHNoLmV4ZSBscy5leGUgdHIuZXhlIGlkLmV4ZSBzZWQuZXhlICMgbWFrZS5leGUN CiMgZW14bG9hZCAtbSAzMCBncmVwLmV4ZSBlZ3JlcC5leGUgZmdyZXAuZXhlIGNhdC5leGUgcm0u ZXhlIG12LmV4ZSBjcC5leGUNCiMgZW14bG9hZCAtbSAzMCB1bmlxLmV4ZSBiYXNlbmFtZS5leGUg c29ydC5leGUgZ2F3ay5leGUNCg0KYWNfY3ZfaG9zdD1pMzg2LXBjLW9zMi1lbXgNClNIRUxMPXNo DQpQQVRIPWBjbWQuZXhlIC9jICJlY2hvICVQQVRIJSIgfCBzZWQgLWUgJ3NAXFxcXEAvQGcnYA0K I0lOU1RBTEw9YHR5cGUgZTovZW14L2Jpbi9pbnN0YWxsLmV4ZXxzZWQgLWUgJ3NAXFxcXEAvQGcn IC1lICdzQC4qIEBAJ2ANCmFjX2N2X3BhdGhfaW5zdGFsbD0ke0lOU1RBTEx9DQpNQUtFPW1ha2UN CkNDPWdjYw0KI0NYWD1nKysNCkNYWD1nY2MNCkFXSz1nYXdrDQpMRVg9ZmxleA0KUkFOTElCPWVj aG8NCllBQ0M9J2Jpc29uIC15Jw0KVEFSPWU6L2VteC9iaW4vdGFyLmV4ZQ0KQVI9L2VteC9iaW4v YXIuZXhlDQpCTVRZUEU9aW50DQpCTUJZVEVTPTQNClBSSU5UQUJMRV9PU19OQU1FPU9TLzINCkNG TEFHUz0nLURfX0VNWF9fIC1ET1MyIC1abXRkIC1EX19TVF9NVF9FUlJOT19fICAtWmV4ZSAtTzIg LWZvbWl0LWZyYW1lLXBvaW50ZXIgLVpiaW4tZmlsZXMgLURzdHJuY2FzZWNtcD1zdHJuaWNtcCAt RHN0cmNhc2VjbXA9c3RyaWNtcCcNCkNYWEZMQUdTPSctRF9fRU1YX18gLURPUzIgLVptdGQgLURf X1NUX01UX0VSUk5PX18gLVpleGUgLU8yIC1mb21pdC1mcmFtZS1wb2ludGVyIC1aYmluLWZpbGVz IC1Ec3RybmNhc2VjbXA9c3RybmljbXAgLURzdHJjYXNlY21wPXN0cmljbXAnDQojQ1hYRkxBR1M9 Jy1nIC1EX19FTVhfXyBfRE9TMiAtWm10ZCAtRF9fU1RfTVRfRVJSTk9fXyAtWmV4ZSAtZm9taXQt ZnJhbWUtcG9pbnRlcicNCkxERkxBR1M9Jy1abXRkIC1EX19TVF9NVF9FUlJOT19fIC1PMiAtWmV4 ZSAtcyAtWnN5c3Ytc2lnbmFscyAtWnN0YWNrIDUxMiAtWmJpbi1maWxlcycNCiNMREZMQUdTPSct ZyAtWm10ZCAtRF9fU1RfTVRfRVJSTk9fXyAtWmV4ZSAtWnN5c3Ytc2lnbmFscyAtWnN0YWNrIDUx MicNCiNtYXJjaD1rNg0KYWNfZXhlZXh0PS5leGUNCmFjX2N2X2V4ZWV4dD0uZXhlDQphY19jdl9w YXRoX19fQ0hHUlA9ZWNobw0KYWNfY3ZfcGF0aF9fX0NIT1dOPWVjaG8NCmFjX2N2X3BhdGhfX19S U0g9ZWNobw0KYWNsX2N2X3JwYXRoPWVjaG8NCg0KIyBteSBhZGRpdGlvbnMNCk00PWY6L3Vzci9i aW4vbTQuZXhlDQpJTlRMQklTT049ZTovZW14L2Jpbi9iaXNvbi5leGUNClBFUkw9cGVybC5leGUN CkVYUFI9ZjovdXNyL2Jpbi9leHByLmV4ZQ0KU0VEPWY6L3Vzci9iaW4vc2VkLmV4ZQ0KYWNfZXhl Y3V0YWJsZV9leHRlbnNpb25zPSIuZXhlIg0KRzc3PWc3Ny5leGUNCkxEPWxkLmV4ZQ0KWEdFVFRF WFQ9ZjovdXNyL2Jpbi94Z2V0dGV4dC5leGUNCkdFVFRFWFQ9ZjovdXNyL2Jpbi9nZXR0ZXh0LmV4 ZQ0KSU5TVEFMTD1lOi9lbXgvYmluL2luc3RhbGwuZXhlDQpYMTFST09UPVgNCg0KIyBmb3Igc3Bl ZWQgdW5jb21tZW50IHRoaXMNCiMgQ0ZMQUdTPSctRF9fRU1YX18gIC1tYXJjaD1rNiAtWm10ZCAt RF9fU1RfTVRfRVJSTk9fXyAgLU82IC1EUkVBTF9JU19GTE9BVCAtRE5PWEZFUk1FTSAtRE9TMiAt V2FsbCAtZm9taXQtZnJhbWUtcG9pbnRlciAtZnVucm9sbC1hbGwtbG9vcHMgLWZpbmxpbmUtZnVu Y3Rpb25zIC1mZmFzdC1tYXRoJyANCiMgQ0ZMQUdTPSctRF9fRU1YX18gLW1hcmNoPWs2IC1abXRk IC1EX19TVF9NVF9FUlJOT19fIC1PNiAtRE9TMiAtbWFsaWduLWxvb3BzPTIgLW1hbGlnbi1mdW5j dGlvbnM9MiAtbWFsaWduLWp1bXBzPTInDQojIGV4cG9ydCBDRkxBR1MNCg0KZnVuY3Rpb24gdGVz dA0Kew0KICBpZiBbICAiJDEiID0gIi14IiBdIDsgdGhlbg0KICAgIHNoaWZ0DQogICAgaWYgWyAt ZiAiJDEiIF0gOyB0aGVuIHJldHVybiA7IGZpDQogICAgaWYgdHlwZSAkMS5jbWQgMT5udWwgMj4m MSAgOyB0aGVuICByZXR1cm4gOyBmaQ0KICAgIGlmIHR5cGUgJDEuZXhlIDE+bnVsIDI+JjEgIDsg dGhlbiAgcmV0dXJuIDsgZmkNCiAgICB4PWB0eXBlICQqIHwgIHNlZCAtZSAnc0BeLiogQEAnIC1l ICdzQFxcXFxAL0BnJyAtZSAnc0BcXC4kQEAnYA0KICAgIGdyZXAgJ15cKCMhXHxbIFx0XSpleHRw cm9jXCknICR4ID5udWwgMj4mMQ0KICBlbHNlDQogICAgYnVpbHRpbiB0ZXN0ICIkQCINCiAgZmkg O1wNCn0NCiMjIyBFT0YgIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw== --_=_=_=IMA.BOUNDARY.IHDSPV138764=_=_=_-- **= Email 3 ==========================** Date: Tue, 31 May 2005 22:08:48 -0700 From: "Steven Levine" Subject: Re: Cleaning up my dev environment (aka want to build mod_jk) In <20050601041351.D8B78B85BC at generation.lgisp.net>, on 05/31/05 at 09:13 PM, "Dave Yeo" said: >Hi Steven, there are most likely as many approaches to setting up a unixy >build enviroment as there are developers. This is definitely true on OS/2. On the Sun I work on things are much easier because things just work. >as where you're building, eg often configure finds /usr/X11R6 all on its >own but only if on the same partition. This is handy as traditional EMX >apps and libs are installed on f: and Innotek apps and libs on I:, good >to keep seperate as a lot of the libs are not compatible. I've got most everything on a single drive and use BEGINLIBATH or Rich Walsh's Run! to avoid most of these issues. >To get configure to work here I use a config.site which configure will >find if it is in $PREFIX/share or defined by %CONFIG_SITE%. $PREFIX >usually defaults to /usr/local. I've started to build up a CONFIG_SITE myself. >I'll attach my config.site which could be a beginning for you though I >really should clean it up when I have time . :-) >Anyways look at my config.site for guidence, don't worry to much about >things in /emx unless configure complains, just have /usr ahead of /emx >in PATH etc and install newer versions in /usr >Dave >ps don't forget C_INCLUDE_PATH etc Thanks for the info. After posting, I went back and thought things through a bit and concluded that I should just start fixing things and forget about using autoconf for a bit. I sorta know about CONFIG_SITE and the various override options. I just have not used this stuff enough to connect the failures to the fixes automatically. IAC, after adding sufficient overrides, configure completed. There are some issues, but it worked well enough to allow make to compile a good bit of code. The libtool that shipped with mod_jk seemed to work correctly once I corrected a couple of missing SED definitions. I stopped at the point where the compiles failed looking for PROT_OPEN in a piece of code that implements a shared memory interface. I'll have to figure out what to do about this. I do have some other annoying problems to figure out. For example, while running under sh.exe, something is stuffing in a /c when I invoke at script with a bare t.sh The workaround is to use: sh t.sh Thanks, Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.67 #10183 Warp4.something/14.100c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ----------------------------------------------------------------------