[M3devel] runpath/unshipped vs. shipped binaries

[Mika Nystrom]

I think what Jay was trying to do sounds right.

I think the binary should run without jumping through hoops if it
hasn't been shipped.  Once shipped it should not be possible to
break it by fiddling around in the build directories.

This does seem to imply that m3ship does something a bit more than
"cp".  I think it would be enough if it reordered the defaults,
from "link with build tree first, /usr/local/lib second" to "link
with /usr/local/lib first, build tree second" (or not at all build
tree).

Is it bad to have m3ship re-link?

    Mika

Olaf Wagner writes:
>Quoting Mika Nystrom <mika at async.caltech.edu>:
>
>>
>> Would this mean that users of CM3 have to set LD_LIBRARY_PATH for
>> things they build themselves but don't ship?
>
>Probably. If the libraries cannot be located by the system in a
>standard path, it needs help. We could probably come up with a small
>script which prints the needed settings for a local M3 workspace.
>
>> I almost never ship binaries because I don't want user "mika" to
>> have write access to the place whither the Modula-3 compiler normally
>> ships.  But I use them... from cron and other places.  Other users
>> may use them too...
>
>Have you got a better suggestion?
>This is really not an M3 problem, but a general Unix question.
>How should dynamic shared object files be found (especially, when
>they are scattered across an M3 workspace)? If we burn in the local
>paths, we need to relink the objects before shipping. I also wouldn't
>like it when some installed program stops to work because the original
>creator made changes to his home directories...
>
>Any ideas?
>
>Olaf
>
>>      Mika
>>
>> Olaf Wagner writes:
>>> Quoting Jay <jay.krell at cornell.edu>:
>>>
>>>> Running uninstalled binaries shall require either LD_LIBRARY_PATH
>>>> or build_standalone(). m3tests uses build_standalone. This is maybe
>>>> why more stuff is build_standalone -- anything that runs uninstalled
>>>>  when doing buildlobal, the various stub code generators.
>>>
>>> Please just use build_standalone for all binaries that are needed
>>> by the build system itself. That shouldn't be many.
>>>
>>> Otherwise, I think setting LD_LIBRARY_PATH is acceptable.
>>>
>>> Olaf
>>> --
>>> Olaf Wagner -- elego Software Solutions GmbH
>>>                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
>>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>>>    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>
>
>
>
>-- 
>Olaf Wagner -- elego Software Solutions GmbH
>                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
>phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
>Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194