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.
Is there a reason you're installing to a "non-standard location"? In Linux that basically means "not listed in /etc/ld.so.conf" so the simplest solution is to add your location there. 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.
David