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.
>
>>> Or are you suggesting that we change the libtool flags, too ?
>>>>
>>>>>
>>>>>> If for some reason CC can't include -m64/-m32 because of our own
>>>>>> build requirements, it could be patched into apr-1-config's CC in
>>>>>> lieu of the existing patch for CFLAGS and CPPFLAGS.
>>>>>>
>>>>>>>>
>>>>>>>> Why should --link-ld and --link-libtool include the --ldflags
>>>>>>>> value too?
>>>>>>>>
>>>>>>> This is related to CR 6772796.
>>>>>>
>>>>>> I'd expect that the user needs to call "apr-1-config --ldflags"
>>>>>> themselves when putting together the command-line.
>>>>>>
>>>>> I think more common usage is to call "apu-1-config --link-(libtool
>>>>> | ld) --libs" .
>>>>> It could be because of the Usage text.
>>>>
>>>> I didn't mean "--ldflags" instead of "--link-(libtool | ld)
>>>> --libs"; I meant in addition to. The variables have different
>>>> meanings. The help output shows building a list of required
>>>> libraries via "apu-1-config --link-(libtool | ld) --libs". It also
>>>> says the application should use the --ldflags value too.
>>>>
>>>>>
>>>>>> --link-ld and --link-libtool specify the arguments for referring
>>>>>> to the library, for when ld is used directly or for when libtool
>>>>>> is used.
>>>>>>
>>>>>> I'm having trouble reproducing that Solaris 10 CR. I would think
>>>>>> that /usr/sfw/lib/libexpat would be in the default search path.
>>>>>
>>>>> It will not be in the system default search path.
>>>>>
>>>>>> "apr-1-config --ldflags" is empty anyway (using the GA build on
>>>>>> Solaris 10 or 2008.11).
>>>>>
>>>>> "apu-1-config --ldflags" on S10 has /usr/sfw/lib
>>>>> On OpenSolaris, it will be empty. But earlier, even on
>>>>> OpenSolaris, some dependent libs were in /usr/sfw/lib.
>>>>
>>>> Oops, I was checking apr-1-config instead of apu-1-config; I now
>>>> follow you with how implicitly adding the --ldflags will make a
>>>> difference with apu-1-config; I just don't think it is appropriate,
>>>> since the application's build process is supposed to query
>>>> --ldflags on its own.
>>>>
>>> Then, do you think we should change the 'Usage' text to highlight
>>> its usage while linking ?
>>> ------
>>> When linking with libtool, an application should do something like:
>>> APR_LIBS="`apr-1-config --link-libtool --ldflags --libs`"
>>> or when linking directly:
>>> APR_LIBS="`apr-1-config --link-ld --ldflags --libs`"
>>> ------
>>
>> "--ldflags" doesn't give you libraries, right?
> Right, but includes the lib path (like 'apr-1-config --link-libtool').
>
>> APR_LIBS is getting set to a list of libraries in the documented
>> invocations
>>
> Fine. I will back out the --ldflags changes.
>
> Thanks,
> Seema.
>
>>>
>>>
>>> Thanks,
>>> Seema.
>>>
>>>>>>> Why is the following change needed? (add -L$libdir if apr-1-config
>>>>>>>> hasn't been installed to its usual place)
>>>>>>>
>>>>>>> When the command "apr-1-config --link-ld --libs" is run from the
>>>>>>> proto area, it should not
>>>>>>> include the runpath value as it points to the proto area.
>>>>>>> This is similar to the --link-libtool change.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Seema.
>>>>>>>
>>>>>>>>
>>>>>>>> ++ if test -n "$install_root"; then
>>>>>>>> ++ flags="$flags -L$libdir -l${APR_LIBNAME}"
>>>>>>>> ++ else
>>>>>>>> ++ flags="$flags -L$libdir -R$libdir -l${APR_LIBNAME}"
>>>>>>>> ++ fi
>>>>>>
>>>>>> _______________________________________________
>>>>>>
>>>>>>
>>>>>> webstack-discuss mailing list
>>>>>> webstack-discuss at opensolaris.org
>>>>>> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
>>>>
>>>> _______________________________________________
>>>>
>>>>
>>>> webstack-discuss mailing list
>>>> webstack-discuss at opensolaris.org
>>>> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
>>
>> _______________________________________________
>>
>>
>> webstack-discuss mailing list
>> webstack-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
