[M3devel] -rpath/origin/CM3_INSTALL on osf

Jay K jay.krell at cornell.edu
Wed Jun 16 09:01:28 CEST 2010


Yes it is mainly about OSF.
Though it is also about running unshipped binaries on all systems -- dynamically linked ones.
For now I'll probably do nothing. Except put this in a todo.txt file I'm going to checkin, I think.
Other stuff first I think.

 - Jay

----------------------------------------
> Date: Tue, 15 Jun 2010 11:04:21 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] -rpath/origin/CM3_INSTALL on osf
>
> Quoting Jay K :
>
>> I'm strongly considering dropping in bin stubs that calculate and
>> set CM3_RPATH and then exec the actual files, in cm3/lib.
>> Thoughts?
>> It'd only be for OSF.
>> And only for shared executables -- wouldn't break cm3 finding config files.
>> Whether or not argv[0] "lies" and remains as bin, or is "truth" and
>> set to lib, unsure.
>>
>>
>> Alternatively, relink on upon ship/install?
>>   That I believe is not unusual practise. It'd also fix NetBSD 4.0..
>>     And it is in some ways better than the current use of $ORIGIN on
>> all other systems.
>>   Augment "boot1.py" to build the entire system, and build a
>> makefile that rebuilds and ships all libraries/executables?
>>   Well, what that probably looks like is augmenting it with Olaf's packaging.
>>    Use that layout, and the method of using cd+cm3, but include all
>> the .c and .s files and have cm3 run assemble/make_lib/ship.
>>    We likely want that anyway, as a more complete form of cross
>> build. Where I define "cross build" in an odd way -- compiling
>>    all the Modula-3 to assembly, but not compiling any of the C or
>> running the assembler or linking.
>
> I think `relink upon ship' would be interesting as an experimental
> option. I'm still not sure if we should really do that or not,
> but if it can be done with little effort, we may play with it.
>
>> There are possible other options, like have the stub determine all
>> the files to load and put them in _RLD_LIST.
>>
>> Or just don't support shared libraries on OSF?
>
> Sounds lame :-)
>
>> Or just distribute existing "boot" for OSF, and require people
>> (Mika) to run scripts/python/boot2.sh?
>>  This is maybe the best short term choice. Doesn't require any work,
>> supports shared libraries.
>>  I think I'll "try" that. Upload a current boot and if Mika can get
>> it to work from there and doesn't mind it, good enough.
>
> OK with me, too, for now, if all users are satisfied with that.
> We're only talking about ALPHA_OSF, aren't we?
>
> Olaf
>
>>  - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: m3devel at elegosoft.com
>>> Subject: RE: -rpath/origin/CM3_INSTALL on osf
>>> Date: Mon, 14 Jun 2010 07:05:26 +0000
>>>
>>>
>>> It looks like you can't use $FOO/t, just $FOO.
>>> So I'll probably use CM3_RPATH.
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: m3devel at elegosoft.com
>>>> Subject: -rpath/origin/CM3_INSTALL on osf
>>>> Date: Sun, 13 Jun 2010 20:43:22 +0000
>>>>
>>>>
>>>> OSF, at least the older version that Mika is running, supports
>>>> -rpath /foo/bar and -rpath ${arbitrary_environment_variable}, but
>>>> not -rpath $origin.
>>>>
>>>>
>>>> Therefore I believe we should pick an arbitrary_environment_variable.
>>>>
>>>>
>>>> I'd like CM3_ROOT, but that is already somewhat/optionally in use
>>>> for the root of the source tree.
>>>> CM3_INSTALL is somewhat/optionally in use to mean what we want here.
>>>> So CM3_INSTALL should probably be it.
>>>>
>>>>
>>>> Alternatively we could pick something really new, OSF_CM3_RPATH or
>>>> such, and drop in wrapper scripts that set it to their location.
>>>>
>>>>
>>>> As well, OSF still has the "old" structure where all the .so files
>>>> are strewn around pkg instead of flattened into lib.
>>>> I'll fix that shortly.
>>>>
>>>>
>>>> You know, the distributions I uploaded have /home/jayk presumably
>>>> all around them.
>>>>
>>>>
>>>> We could also "stage" installs to somewhere unique/arbitrary and
>>>> require user to set LD_LIBRARY_PATH.
>>>> But CM3_INSTALL seems adequate, maybe better.
>>>>
>>>>
>>>> Possibly CM3_INSTALL_5_8, CM3_INSTALL_5_9, etc.
>>>> Though really, better than that is probably wrapper scripts that
>>>> set CM3_INSTALL.
>>>> And wrapper scripts could be executables, put the real executables
>>>> in lib or such.
>>>>
>>>>
>>>> - Jay
>>>>
>>>
>>
>
>
>
> --
> 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
>
 		 	   		  


More information about the M3devel mailing list