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.

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.

--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.  
"apr-1-config --ldflags" is empty anyway (using the GA build on Solaris 
10 or 2008.11).
>
>> 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


Reply via email to