On Wed, Apr 21, 2004, Karl Vogel wrote:
> More brain-deadness from Tru64...
>
> The perl.spec has a Configure option
>
> -Doptimize="%{l_cflags} -O"
>
> This parameter is used to build up the linker flags, resulting in the
> following linker command line:
>
> ld -shared -expect_unresolved "*" -O -msym -std -s -L/tmp/openpkg/lib
>
>
> Now it appears that the linker doesn't understand the '-O' but it does
> understand -O0 upto -O3. So a possible fix would be to use:
>
> -Doptimize="%{l_cflags} -O2"
>
> I think this will work on all openpkg supported platforms?!
>
> For reference, the 'ld' man page part:
>
> -O0 Turn off all code optimizations performed by the linker. This is the
> default.
>
> -O1 Turn on the code optimizations that can be performed quickly with lit-
> tle additional time and memory overhead during the link. Note that cc
> passes -O1 as the default when linking.
>
> -O2, -O3
> Turn on all code optimizations that can be performed by the linker.
>
> I've verified that the packages builds on Tru64 with -O2.
Well, the Configure options actually reads -Doptimize="%{l_cflags -O}"
which means that the l_cflags macro is called with option -O. This in
turn runs "rpmtool cflags -O %{l_cc}" and there the -O input option
becomes a real -O option in the output (because no "gcc" is found,
else it would output -O2 -pipe). So, the correct fix is not to patch
perl.spec from "perl" package, but to patch rpmtool from the "openpkg"
package to know about this additional Tru64 issue.
This fix is now part of the latest openpkg-20040421-20040421 bootstrap
package from OpenPKG-CURRENT. Upgrade to this version, try again to
build "perl" and all should be fine related to this ld(1) option
fiddling.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List [EMAIL PROTECTED]
