On 12.10.2021 16:31, Rony G. Flatscher wrote:
>
> Committed <http://sourceforge.net/p/oorexx/code-0/12289>: "20211012 Unix:
> samples now in proper
> 'share/ooRexx/samples' subdirectory, native samples now as well; if
> DOC_SOURCE_DIR defined
> installs Unix related documentation to proper 'share/ooRexx/doc'
> subdirectory."
>
> ---
>
> A few things:
>
> * please check whether the documentation for Unix includes all Unix related
> documentation,
> * the wpipe-examples on Windows (rexxapi1.c, apitest1.rex, ...) use
> different names than the
> Unix (rexxasp1.c, aspitest1.rex, ...) examples which is a little bid odd,
> * the Unix standalone programs (e.g. samples/api/callrexx/callrexx1) are
> not able to find
> librexx.4.so, one needs to prepend "LD_LIBRARY_PATH=/usr/local/lib" in
> order for them to find
> the dynamic link library; not sure why this is
>
Doing a "readelf -d callrexx1" the RUNPATH is set to "$ORIGIN/../lib" (this is
also the case with
the other created binaries) the same as for rexx and its binaries.
After changing CMAKE_INSTALL_RPATH to
(SET CMAKE_INSTALL_RPATH
"$ORIGIN;$ORIGIN/../${CMAKE_INSTALL_LIBDIR};/usr/local/lib;/usr/lib")
the compiled sample programs will be able to run! It is as if an existing RPATH
restricts the search
for libraries to it; currently just a single directory is defined:
"$ORIGIN/../${CMAKE_INSTALL_LIBDIR}".
So, should we change CMAKE_INSTALL_RPATH to add additional locations where to
look for libraries?
And if so, would the above list be acceptable?
> * the wpipe* examples create a dynamic link library, but running the Rexx
> scripts in those
> directories will report "Error 43.1: Cannot find routine "ASPILOADFUNCS"
>
> ---rony
>
>
>
> On 12.10.2021 12:45, Rony G. Flatscher wrote:
>> On 11.10.2021 19:31, Rick McGuire wrote:
>>>
>>> On Mon, Oct 11, 2021 at 12:46 PM Rony G. Flatscher <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> While looking through the native samples I noticed that
>>>
>>> * in the Windows branch there are makefiles. Are these makefiles
>>> still needed now that we
>>> use CMake?
>>>
>>> The makefiles are not used for the build, the makefiles are part of the
>>> sample, allowing the
>>> user to build them once they are installed on their system.
>> Ah, I see!
>>>
>>> *
>>>
>>>
>>> * in the Unix branch there are no statements comparable to the
>>> windows branch that direct
>>> the install, which might be the reason why on Unix native sample
>>> binaries are wrongfully
>>> placed into the bin and lib directories. Not really knowing CMake
>>> it looks like adding
>>> the Windows installation statements to the Unix branch would be
>>> possible?
>>>
>>> If it's possible for Windows, then yes it is possible for Unix as well. It
>>> probably should be done.
>> Will look into it.
>>>
>>> * If so, wouldn't it make sense to fold the native samples for
>>> Windows and Unix and have a
>>> single CMakeLists.txt to drive the compilation and installation of
>>> the native samples?
>>>
>>> No, platform specific branches should be kept separate. What applies to one
>>> platform doesn't
>>> necessarily apply to the others.
>> +1
>>>
>>> * on Unix (Linux) the non native samples currently get installed to
>>> "@/share/ooRexx"
>>> rather than into "@/share/ooRexx/samples", where "@" would be
>>> "/usr" on Ubuntu. Should
>>> that be corrected?
>>>
>>> Probably. For Unix, this is currently defined as
>>> this: ${CMAKE_INSTALL_PREFIX}/share/${CMAKE_PROJECT_NAME}. The doc location
>>> variable also
>>> doesn't appear to be defined.
>>>
>>>
>>> *
>>>
>>>
>>> o Also, it seems that nowadays user installed applications should
>>> go into "/usr/local"
>>> instead? If so, should that be corrected or is this driven by
>>> CMake and should be
>>> left to it therefore?
>>> * the Unix definitions do not create/install the pdf documetnation
>>> files; would it make
>>> sense to install them on Unix too, if the documentation pdfs are
>>> present? If so, where
>>> should they be looked for and where should they be installed to on
>>> Unix, maybe to "@/
>>> share/ooRexx/doc"?
>>>
>>> It probably would make sense to include these.
>>
>> Will look into it.
>>
>> Thank you, Rick!
>>
>> ---rony
>>
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
