enabling shared builds

enabling shared builds

[Andrew Cagney]

Hi,

At the moment frysk's build system links against its own libraries 
statically; doing this avoids any issues picking up the wrong library 
(for instance patchd vs installed libunwind et.al.), it also leads to 
large binaries (system libraries are linked dynamically).

I'm looking at switching to changing much of frysk to be dynamic but 
this leads to some in-tree vs ex-tree fun.  For instance, while in-tree 
test programs such as:
    ./TestRunner
and
    ./frysk-gui/frysk/gui/FryskGui
are built to find their libraries in the build tree (using RPATH stuff), 
programs intended to be run from the install tree such as:
    frysk-core/bindir/fhpd
will not.  Consequently, with shared enabled, programs such as fhpd will 
either fail to run or will run incorrectly (using previously installed 
libraries).

There are several ways to address this; and before making this change I 
think we should consider our options:

- wire build RPATH into binaries
Doesn't work: the installed binary could load incorrect build-tree 
solibs and vice versa

- rely on the developers to provide the path explicitly:
   LD_LIBRARY_PATH=<path-to-all-solibs> ./frysk-core/frysk/bindir/fhpd
(chance of us getting that right? 0 :-)

- provide a wrapper script that sets the environment vis:
   ./BuildTree ./frysk-core/frysk/bindir/fhpd

- have 'TestRunner' export LD_LIBRARY_PATH before invoking any utilities

- create two versions of the binary; one for build-tree and one for 
install tree

- switch to install-tree testing
Would mean breaking configure convention and set --prefix=.  On the 
other hand it would mean only testing one way.

Thoughts, other ideas.

Andrew

Re: enabling shared builds

[Phil Muldoon]

Andrew Cagney wrote:
> There are several ways to address this; and before making this change 
> I think we should consider our options:
>
> - wire build RPATH into binaries
> Doesn't work: the installed binary could load incorrect build-tree 
> solibs and vice versa

yuck.

>
> - rely on the developers to provide the path explicitly:
>   LD_LIBRARY_PATH=<path-to-all-solibs> ./frysk-core/frysk/bindir/fhpd
> (chance of us getting that right? 0 :-)

ugh

>
> - provide a wrapper script that sets the environment vis:
>   ./BuildTree ./frysk-core/frysk/bindir/fhpd

Feasible, but a binary should just "work" without lots of wrappers.

>
> - have 'TestRunner' export LD_LIBRARY_PATH before invoking any utilities

Don't like.

>
> - create two versions of the binary; one for build-tree and one for 
> install tree
>

Don't like.

> - switch to install-tree testing
> Would mean breaking configure convention and set --prefix=.  On the 
> other hand it would mean only testing one way.
IMO should be install tree testing anyway, as it simulates the 
environment when Frysk is deployed much more accurately. +1 for this way,

Regards

Phil

Re: enabling shared builds

[Petr Machata]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

Andrew Cagney wrote:
> - create two versions of the binary; one for build-tree and one for
> install tree

I like this one.  autogen.sh --devel would add rpath to binaries,
--release would not.  Requiring one of --devel and --release would even
make sure people don't forget to specify the "flavor" option.

> - switch to install-tree testing
> Would mean breaking configure convention and set --prefix=.  On the
> other hand it would mean only testing one way.

That's another possibility I kind of like, but running make install each
time you want to test one-liner fix is inconvenient.  Frysk turn-around
time is already too bad.

> Thoughts, other ideas.
> 
> Andrew
> 

PM


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: enabling shared builds

[Kris Van Hees]

> Andrew Cagney wrote:
> - switch to install-tree testing
> Would mean breaking configure convention and set --prefix=.  On the other 
> hand it would mean only testing one way.

Definitely a big 'no' on this one.  For one, forcing an install of development
builds in order to be able to test it is asking for trouble.  Secondly, it is
(hopefully) going to be more likely in the future that a system will have frysk
already installed as part of the OS install, and a development build shouldn't
wipe out the installed version for sure.  Thirdly, it is common practice with
software projects to follow a 'build -> test -> install' sequence, which is
generally the most sensible way because you wouldn't want to install something
that is broken, i.e. test before you install.

	Cheers,
	Kris

Re: enabling shared builds

[Andrew Cagney]

Kris Van Hees wrote:
>> Andrew Cagney wrote:
>> - switch to install-tree testing
>> Would mean breaking configure convention and set --prefix=.  On the other 
>> hand it would mean only testing one way.
>>     
>
>   
Seems I've created a little confusion with "and set -prefix".  I don't 
think anyone was thinking of installing into /usr, which, if nothing 
else, would require root privileges..  --prefix would need to be pointed 
at something like $BUILD/_oinst and then overridden when doing a system 
build/install.

Andrew


> Definitely a big 'no' on this one.  For one, forcing an install of development
> builds in order to be able to test it is asking for trouble.  Secondly, it is
> (hopefully) going to be more likely in the future that a system will have frysk
> already installed as part of the OS install, and a development build shouldn't
> wipe out the installed version for sure.  Thirdly, it is common practice with
> software projects to follow a 'build -> test -> install' sequence, which is
> generally the most sensible way because you wouldn't want to install something
> that is broken, i.e. test before you install.
>
> 	Cheers,
> 	Kris
>   

Re: enabling shared builds

[Kris Van Hees]

On Thu, Dec 13, 2007 at 06:19:06PM -0500, Andrew Cagney wrote:
> Kris Van Hees wrote:
>>> Andrew Cagney wrote:
>>> - switch to install-tree testing
>>> Would mean breaking configure convention and set --prefix=.  On the other 
>>> hand it would mean only testing one way.

> Seems I've created a little confusion with "and set -prefix".  I don't 
> think anyone was thinking of installing into /usr, which, if nothing else, 
> would require root privileges..  --prefix would need to be pointed at 
> something like $BUILD/_oinst and then overridden when doing a system 
> build/install.

That does indeed resolve the issue of overwriting an existing installation
but it does nothing to avoid the fundamental problem with requiring to do
the install step prior to running development tests.  This is exactly the
kind of situation where software engineering commonly separates the
development testsuite from a release testsuite (which is typically done
on an installed version of the project).

I am sure someone can come up with an existing project that does require
installation in some location prior to running development level tests, but
I honestly cannot remember ever encountering a single one.  We're facing a
quite common problem, so I think we ought to be able to pick an already well
established solution, and run with it.

	Cheers,
	Kris