[mercury-users] Problem with shared libraries with Mercury 0.13.1 on Mac OS X 10.4.11

[Julien Fischer]

Hi,

On Tue, 6 Jan 2009, Markus Morawitz wrote:

> I was able to install Mercury 0.13.1 on Mac OS X 10.4.11 running gcc 3.3 
> without any problem.
> Also most of the tests in mercury-tests-0.13.1 succeeded.
>
> Now I am trying to install and use some of the provided libraries in 
> mercury-extras-0.13.1.
> Especially I looked at the complex_numbers library.

A lot of the Mmakefiles in the extras distribution are (1) very old
and (2) (probably) rather Linux specific.

> There I noticed a general problem with installing shared libraries on Mac.
>
> Although the variable INSTALL_PREFIX is correctly set in the Mmakefile
> to <base-mercury-path>/extras and the command mmake install also copies
> the resulting files (including the shared library) to the correct place under
> <base-mercury-path>/extras.
>
> But the library itself is linked with a false install-name. The path within 
> install-name
> is constructed independent of the setting in INSTALL_PREFIX only on 
> <base-mercury-path>.
> The consequence is that the resulting executables (which can be linked 
> correctly) are not able to
> run because dyld is searching the library in a false path.

A workaround when this happens is to set the environment variable
DYLD_LIBRARY_PATH to point to the correct path.

> Further investigation has revealed that the the generated dependency file 
> (with mmake depend) *.dep
> is the main source of this error. There the rules for generating and linking 
> the shared library uses the
> parameter -install-name with a path independent of the settings of 
> INSTALL_PREFIX in the Mmakefile
> always pointing to the base mercury installation.
>
> The general problem seems to be that the command "mmc --generate-dependencies 
> command"
> responsible to produce the *.dep file is not aware of the setting of the 
> variable INSTALL_PREFIX.
> But the part responsible to install (copy) the library to the right place 
> (rules in Mmake.rules) works
> fine because INSTALL_PREFIX is used.
> Also the making and linking of an executable linked to the library works fine 
> using the variables
> EXTRA_LIB_DIRS and EXTRA_LIBRARIES.
> Only the execution itself invoking dyld fails again.
>
> I also found a workaround.
>
> I changed the definition of the variable MCD within Mmake.vars:
>
> original definition of MCD in Mmake.vars:
> MCD		= $(MC) --generate-dependencies
>
> my definition of MCD in Mmake.vars:
> MCD		= $(MC) --generate-dependencies --install-prefix 
> $(INSTALL_PREFIX)
>
> With this definition the *.dep files are generated correctly using the 
> settings of INSTALL_PREFIX in the Mmakefile.
> The install-name of the library then is according to the place where the 
> libraries get copied by the install target.
> And dyld can find the libraries.

A simpler way is to include the following line in the Mmakefile:

     MCFLAGS = --shlib-linker-install-name-path $(INSTALL_PREFIX)

I'm not sure why the --shlib-linker-install-name-path option
doesn't get included in the .dep file on OS X, however ...

I would suggest using mmc's --make option instead of mmake in
any case.  With the complex_numbers library, just invoke the
compiler as follows:

     mmc --install-prefix /Dir/To/Install/In --make \
        libcomplex_numbers.install

Cheers,
Julien.
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------