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.
> 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.
> --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.
Regards,
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
