[m-dev.] Re: Two problems building/installing user-defined libraries, Mac OS-X

[Mark Brown]

Hi Doug,

On 17-Mar-2006, doug.auclair at logicaltypes.com <doug.auclair at logicaltypes.com> wrote:
> Dear all,
> 
> On the ROTD-2006-03-15, I am unable to build or to install libraries
> I am creating on powerpc.apple.darwin8.3.  This is NOT an issue on
> other platforms (specifically, I am able to build, to install, and to use
> libraries that I create on sparc.sun.solaris2.8).

I've just built and installed ROTD-2006-03-18 without any problems.  I then
used the installed compiler to build a workspace checked out from the
repository earlier today, also without any problems.

> 
> The first problem the compiler complains about is that it cannot build
> the dynamic library because it is unable to find libgcc.a.

It appears that your installation of gcc is broken...

> Actually, this
> has been a recurrent problem in my builds.  What I do to build a compiler
> distribution is to remove from Mmake.common and scripts/ml the
> `/usr/bin/gcc-3.3 --print-libgcc-file-name` command, because on my
> architecture, this causes the system to error out (as on Macs, apparently,
> libgcc.a is called something else, like libgcc_s_1.0.dylib, etc -- this may
> actually be a bug with gcc).

No, the dylib file is a different kind of library.  On my system (darwin 8.5),
`gcc --print-libgcc-file-name' prints /usr/lib/libgcc.a, which is a link to
/usr/lib/gcc/darwin/default/libgcc.a, which certainly exists.

Note that running `gcc-4.0 --print-libgcc-file-name' produces

	/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc.a

which also exists, so it appears that this option works even for a version
of gcc which is not the default.

The datestamps on all of the library files, links, binaries, etc, indicate
that they haven't changed in the past year, so I doubt this is an issue
that has only been fixed in 8.5.

> -----
> 
> The other problem is that when I go to install this finally build 
> static library,
> the install process dies on the first implementation, saying that it cannot
> find array.mih

I generally get this error when I try to compile in a `hlc' grade when no
such grades are installed.

>From the error log you provided, it seems you were installing in grade
hlc.gc...

> (by the way, I do not import the array module anywhere in my
> code) ... when I 'ls -l' where it's looking for this .mih file,

...but you are looking in a directory under reg.gc for the file, which is
a different grade.

> the path goes
> into infinite recursion.

I can't reproduce this.  Cycles in soft-links are not uncommon, and
shouldn't normally cause problems.

> Is this part of the problem, or do I need 
> to set some
> environmental variable to assist the install process along?

Read the documentation for the LIBGRADES variable in section 5 of the
user's manual.  Set its value to a subset of the grades which are actually
installed.  You can set it in the environment, in the Mmakefile, or in the
Mercury.options file if using mmc --make.

To find out which grades are installed, either consult the output of
./configure (in configure.log) or look at the directories under
$(PREFIX)/lib/mercury/lib to see which ones have libraries.

Cheers,
Mark.

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------