[csw-dev] [libart 0002824]: RPATH contains /opt/csw/lib/sparcv9/$ISALIST

Dagobert Michelsen dam at blastwave.org
Mon Mar 24 22:20:05 CET 2008


Hi James.

I moved this to the new dev-list, as it may be worth
conserving the discussion :-) That's why I am keeping
most of the discussion fully quoted.

Am 24.03.2008 um 20:52 schrieb James Lee:
> On 24/03/08, 19:48:09, Dagobert Michelsen <dam at blastwave.org> wrote
>>>   export OPT="-fast -xnolibmopt -xspace -xtarget=ultra2 -xarch=v8
>>> -xstrconst"
>>>   make -e clean all
>>>   mv cswstage cswstage.generic
>>>
>>>   export OPT="-fast -xtarget=ultra3i -xarch=v8plusb -xstrconst"
>>>   export MLIB="-lm"
>>>   make -e clean all
>>>   mv cswstage cswstage.sparcv9+vis2
>
>> Ok, so you have different optimizer flags for each ISA, right?
>> And you have different exported variables per ISA.
>
> Yes.  The flags are not just about matching the instruction set.
> The flags are to suit the needs of the binaries.  Eg, a rarely used
> utility or one used for < 100ms is best optimised for size and
> certainly doesn't need arch variants.  The binaries that run for
> hours get everything I can give them.  It's not even true that the
> expected flags work best.
>
> I'm even putting v8 files in the v9 isaexec directory because
> Solaris 8 lacks the v8plusb isaexec entry (works with bins, not libs).

Looks quite like a hack... Any idea why the libs don't work?
I always thought the linker inspected the libs and decided
if the memory model is suitable instead of looking at the
directory name.

>> Why do you
>> use libm only for certain ISAs?
>
> Size optimisation.  It's really the inline libs I'm controlling
> here.

I see. So it would make sense to you to control the exported
variables per ISA?

>>> make actual calls a makefile that calls a special rmakefile, I  
>>> digress
>>> but somewhere in GAR it said make had to be gmake - whoa!!!
>
>> I'm sorry, I can't follow you here. Is gmake a problem?
>
> Yes when a makefile is written for make.  Now I could rewrite the
> makefile or I could use old make - easy choice.

If it is needed we can provide rules for ccsmake and xpg4make
which can easily selected if that helps you.

> Are yes, do we
> have imake capabilities?

Yes, those were inherited:

> # configure a package that uses imake
> # FIXME: untested and likely not the right way to handle the
> # argumentsconfigure-%/Imakefile:
>         @echo " ==> Running xmkmf in $*"
>         @cd $* && $(CONFIGURE_ENV) xmkmf $(CONFIGURE_ARGS)
>         @$(MAKECOOKIE)



> Maintainers with packages that just
> "configure && gmake install" are very lucky.

You can easily change behaviour to suit your needs with
   CONFIGURE_SCRIPTS = custom
   BUILD_SCRIPTS = custom

configure-custom: ...

build-custom: ...

>>> ARCHES="sparcv8 sparcv8plus+vis sparcv9+vis2"
>>> PROGS="rpict rvu rtrace ranimove ximage pfilt"
>>>
>>> for arch in $ARCHES
>>> do
>>>   mkdir -p `pwd`/cswstage/opt/csw/bin/$arch
>>>   for prog in $PROGS
>>>   do
>>>     # repeat in arch loop for simplicity...
>>>     rm -f cswstage/opt/csw/bin/$prog
>>>     cp cswstage.$arch/opt/csw/bin/$prog cswstage/opt/csw/bin/$arch/
>>> $prog
>>>   done
>>> done
>
>> Does PROGS contain bin/* or is it a subset?
>
> Just those 6, of about 125.  I definitely don't want 4 arch examples
> all.

Okay.

>> Additionally, you configure the binaries all to standard
>> locations (like bin/) and then move them to the ISA
>> subdirs. In the current multi-ISA GAR the individual
>> ISA-builds are configured to already use the ISA-subdirs
>> (like bindir=bin/sparcv9) which looks cleaner to me.
>
> That's where the current makefile puts them, it's not worth fighting,
> just go with the flow and move after.  There is no point it changing
> the build (and passing back) because only a packager wants the options
> and isaexec, anyone building for themselves knows their target.

Yes, but currently GAR resets bindir, libdir, etc. to the
ISA subdirectories automatically. This introduces some complexity
which I thought was necessary, but I am doubting now if this
could be reverted to the style you use. This would make the
GAR design quite a bit simpler.

> I know it takes the machine longer to build 5 variants and then
> only use a small number of each but the machine's time is cheap,
> mine is short (even if it's cheap ;-) ).
>
>>> ie, "manually", in this case it is almost regular but still a  
>>> country
>>> mile from wanting each example of each arch.  I really can't see an
>>> easier and clearer way of expressing these actions.
>
>> The steps are fairly straight-forward, and so a decent
>> abstraction could be added to GAR. I'll prepare something
>> for further discussion.
>
> Just keep in mind the need for flexibility.   I'm not against
> automation and build system in principle - the first thing I do with
> any project is waste 50% of the time working out how to do the job
> twice as quickly.  I am against systems that don't help.

I hereby allow you to kick me as long as you think
GAR doesn't help you ;-)

>>> For special optimisation, simplistically either speed or
>>> space, I want to be able use whichever binary benefits from each
>>> set of
>>> flags.
>
>> I see. Thanks for the input. Are you currently doing
>> these steps manually or do you have a script?
>
> I just record these steps in a script file, then run it.  It's all
> logged and repeatable and kept for the required 3 GPL years.
>
>
>
>> I would
>> like to convert this to GAR as a reference for my
>> "5 non-trivial packages" as it uses an extreme diversity
>> in compiler flags and ISA. As you have done quite some
>> work with compiler optiomization flags it would be great
>> if you could review the optimizer flag section in the
>> multi-ISA gar.conf.mk:
>>    <http://svn.blastwave.org/trac/browser/csw/branches/dam/automatic-
>> multiarch-compile/gar.conf.mk#L261>
>
>
> How about povray where I do profiling runs and feedback that back
> for recompilation?
>
> build(){
>
> for makefile in $(find . -name Makefile)
> do
>     gsed -i -e '/^CXXFLAGS.*/s//CXXFLAGS='"$FLAGS"' - 
> xprofile=collect/'
> $makefile
> done
>
>
> rm -rf povray.profile
> gmake clean
> gmake -j $(psrinfo | wc -l)
>
> for i in $(find scenes -name \*.pov)
> do
>     echo $i
>     echo ${i%/*}
>     unix/povray -D +A +L ./include/ +L ${i%/*}/ $i
> done
>
> for makefile in $(find . -name Makefile)
> do
>    gsed -i -e 's~^CXXFLAGS.*~CXXFLAGS='"$FLAGS"'
> -xprofile=use:'$(pwd)'\/povray~' $makefile
> done
>
> gmake clean
> gmake -j $(psrinfo | wc -l)
>
> mkdir -p cswstage/opt/csw/bin/${ARCH}
> cp unix/povray cswstage/opt/csw/bin/${ARCH}
>
> }
>
> FLAGS='-fast -xnolibmopt -xspace -xtarget=ss20 -xarch=v8'
> ARCH=sparcv8
> build
>
> FLAGS='-fast -xtarget=ultra2'
> ARCH=sparcv8plus+vis
> build
>
> if isalist | grep vis2 ; then
> FLAGS='-fast -xtarget=ultra3i -xarch=v8plusb'
> ARCH=sparcv9+vis2
> build
> fi

Fine. I'll give it a try when libiconv is finished and GAR
gets refined.


Thanks!

   -- Dago



More information about the devel mailing list