Jeff Trawick wrote: > Jeff Trawick wrote: >> Seema Alevoor wrote: >>> >>> >>> On 02/26/09 06:27, Jeff Trawick wrote: >>>> Seema Alevoor wrote: >>>>> >>>>> Jeff Trawick wrote: >>>>>> Seema Alevoor wrote: >>>>>>> >>>>>>> >>>>>>> On 02/24/09 21:22, Jeff Trawick wrote: >>>>>>>> Seema Alevoor wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 02/24/09 06:29, Jeff Trawick wrote: >>>>>>>>>> Seema Alevoor wrote: >>>>>>>>>>> Please review the webrev at >>>>>>>>>>> http://cr.opensolaris.org/~seema/6782613/ >>>>>>>>>>> >>>>>>>>>>> Main changes: >>>>>>>>>>> * --cflags includes CFLAGS and EXTRA_CFLAGS >>>>>>>>>>> * --link-ld and --link-libtool options includes --ldflags >>>>>>>>>>> option value. >>>>>>>>>>> >>>>>>>>>> These all sound like APR fixes, and not issues with our >>>>>>>>>> integration. Is that right? What was broken? I just see the >>>>>>>>>> -m32/-m64 issue in the CR. >>>>>>>>>> >>>>>>>>> Evaluation has details about why --ldflags change was necessary. >>>>>>>>> >>>>>>>>>> I understand that --cflags without the user-specified CFLAGS >>>>>>>>>> broke with 64-bit builds, and I've posted to dev at apr asking >>>>>>>>>> about the history (it is a hindrance people have put up with >>>>>>>>>> for too long). >>>>>>>> >>>>>>>> According to a highly esteemed APR colleague, the usual >>>>>>>> solution for 64-bit builds, and ABI issues in general, is to >>>>>>>> include such flags in CC. CFLAGS may include flags not >>>>>>>> appropriate to pass on to applications. I've tweaked my >>>>>>>> personal Apache/APR build scripts to move "-m64" from CFLAGS to >>>>>>>> CC, and can avoid the ugly "apxs -Wl,-m64 -Wc,-m64 ..." hack, >>>>>>>> and apr-1-config output looks good too. >>>>>>>> >>>>>>>> For our build we own all these settings and can determine >>>>>>>> whether we only include items in CFLAGS that can be passed on >>>>>>>> to applications so the choice isn't absolutely critical, but it >>>>>>>> would be great to follow the normal path. >>>>>>>> >>>>>>> For our builds, common flags are defined in the master makefile >>>>>>> and they are all >>>>>>> part of CFLAGS variable. >>>>>> >>>>>> Okay, so we clearly have to do something out of the ordinary. >>>>>> >>>>>> I'd rather see us edit the --cc value in apr-1-config to match a >>>>>> recommended APR build than extend the meaning of >>>>>> --cflags/--cppflags in both apr-1-config and apu-1-config. >>>>>> >>>>> When we use libtool to compile a module, it will use build time >>>>> CFLAGS. Shouldn't the user be exposed to same set of flags while >>>>> using apr-1-config/apu-1-config ? >>>> The apr-1-config flags seem safer, since as we bump up optimization >>>> on our code (verified by our testing) we don't affect the >>>> optimization of the user's code, possibly breaking it or rendering >>>> it difficult to debug. >>>> >>>> I don't know this with absolute certainty, but in general I trust >>>> that what's good for APR on other platforms is good for OpenSolaris >>>> too. >>>> >>>> I did eyeball the compile difference between apxs (which uses >>>> libtool) vs. building the command using apr-1-config and didn't >>>> notice anything harmful. >>>> >>>> >>> So, you are suggesting that we change >>> 1. the --cc option to include the essential build time CFLAGS >>> 2. retain apr-1-config's CFLAGS as EXTRA_CFLAGS (back out the >>> --cflags and --cppflags changes) >>> 3. no change to libtool flags , >>> right ? >> >> right >> >> This should bring us in alignment with a normal APR build. >> >> For CC, the only essential build time flag missing AFAICT is -m64. It >> is in CFLAGS for us because our build setup doesn't follow the >> recommended APR mechanism -- setting CC to "cc -m64" for 64-bit builds. >> > oops, I wasn't ready to press the "Send" button... > > Just to be sure about everything, I'll work on a few testcases for > using different outputs of the build to build a third-party app, try > them with two different APR builds (CC="cc -m64" vs. CFLAGS="-m64"), > report on the negative aspects of each one, and see where the "-m64" > ends up in both situations. > > (understanding that we won't actually change our build to use CC="cc > -m64" but are considering editing the build files to act like it)
All tThe differences in APR and APR-Util install tree are: apr-1-config: -CC="cc" -CPP="cc -E" +CC="cc -m32" +CPP="cc -m32 -E" apr_rules.mk: -CC=cc +CC=cc -m32 -CFLAGS=all-the-extra-compilation-flags -m32 +CFLAGS=all-the-extra-compilation-flags libtool: -LTCC="cc" +LTCC="cc -m32" -LTCFLAGS="all-the-extra-compilation-flags -m32" +LTCFLAGS="all-the-extra-compilation-flags" # A language-specific compiler. -CC="cc" +CC="cc -m32" --/-- On the Apache side, config_vars.mk has the same settings for CC and CPP as apr-1-config. It has the CFLAGS settings like libtool too. --/-- It still comes down to deciding whether or not apr-1-config from OpenSolaris should include all the externally-defined CFLAGS/CPPFLAGS, unlike normal apr-1-config. If we patch in the -m32/-m64 in the four or five places above, we'll be consistent and still allow 64-bit compiles. The -m32/-m64 inside CFLAGS/LTCFLAGS in libtool and apr_rules.mk won't hurt anything.
