On 09/04/13 11:28, David Matthews wrote:
On 08/04/2013 21:22, Phil Clayton wrote:
On 08/04/13 12:21, David Matthews wrote:
I have found something called config.rpath which seems to be part of the
GNU portability library. This appears to calculate potentially useful
values for passing rpath to linkers. acl_cv_hardcode_libdir_flag_spec
may of use - I don't know. Nor do I know how you would go about using
it!
Alternatively, LD_RUN_PATH could be set for the link command. Although
probably benign if unsupported, I don't know how portable it is to other
platforms.
Presumably I am experiencing this linker path issue because I have
installed Poly/ML to a non-standard location(?) In such a set up, maybe
it is reasonable to require LD_LIBRARY_PATH to be set for executables
from polyc. Perhaps it is worth considering what would users expect if
the compiled executables are copied to different systems.
I found some references to rpath in the porting guidelines for Debian.
The general recommendation was to avoid it because while it would work
for one library it might have an adverse effect if an application used
other shared libraries.
Yes, it appears people feel quite strongly about that, so probably best
avoided!
Is there a reason you're installing to a "non-standard location"?
I install to /opt/polyml/polyml-${version} to allow multiple versions to
coexist, for at least two reasons:
1. To quickly allow (performance) regression tests to be performed
between versions of Poly/ML.
2. I have needed a pre-release due to an enhancement not yet available
in the main release. (For example, a while ago I was making use of an
FFI enhancement before 5.5 was released.)
Other people may have other reasons for multiple versions.
In
Linux that basically means "not listed in /etc/ld.so.conf" so the
simplest solution is to add your location there.
You're right, I should really do that. In fact, on Fedora, I would add
the file
/etc/ld.so.conf.d/polyml-${version}.conf
that contains the libdir.
Another solution is to
use static linking so you don't have to worry about it. Use ./configure
--disable-shared.
>
My idea with the polyc script was to try to make it easy for people
familiar with C to be able to try out Poly/ML. Of course it may evolve
beyond that but for the moment I want to keep it simple.
I misunderstood the motivation for polyc. I thought that it was to
allow those without compiling/linking knowledge to easily build
executables, i.e. to de-skill the process. Whilst such users may
realize that
./configure --prefix <non-standard location>
requires
PATH=${PATH}:${bindir}
they would not realize that they need (assuming no super-user privileges)
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${libdir}
Phil
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
