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.
> 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?
APR_LIBS is getting set to a list of libraries in the documented invocations
>
>
> 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
