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 ?
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`"
------
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
