[m-dev.] for review: add threads options to ml

Fergus Henderson fjh at cs.mu.OZ.AU
Fri Apr 7 03:52:12 AEST 2000


On 06-Apr-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 06-Apr-2000, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> >  
> > > > 	Add option `--use-old-osf-thread-libs' to pass
> > > > 	`-lpthreads -lc_r' to the linker on DEC OSF/1. 
> > > > 	Linking the Aditi API library fails when no
> > > > 	options are passed.
> > > 
> > > That one looks like a bit of a wart to me.
> > > Couldn't this be handled by an autoconf test?
> > 
> > Which machine did you use to test your change to the OSF/1 thread
> > library options?
> 
> I think it was murlibobo.
> 
> > On murlibobo, I can't link any program using threads without
> > `-lpthreads -lc_r'. 
> 
> Hmm... maybe my change to scripts/ml.in was just plain wrong?
> I'll investigate further and get back to you.

I managed to reproduce the problem.  With `-lpthreads -lc_r' (i.e.
scripts/ml.in version 1.75, the one before my change),
when I try to build the compiler with `GRADE=asm_fast.gc.par',
I get the following error when linking mercury_compile:

    Error: Undefined:
    vm_page_size
    swtch_pri
    vm_allocate
    task_self_
    mach_init
    thread_self
    port_allocate
    mach_error_string
    port_set_backlog
    bind_thread_to_cpu
    thread_create
    thread_terminate
    thread_suspend
    thread_info
    thread_abort
    thread_resume
    msg_receive
    msg_send
    port_status
    vm_deallocate
    thread_get_state
    thread_set_state
    collect2: ld returned 1 exit status
    gmake: *** [mercury_compile] Error 1

With my change (scripts/ml.in version 1.76), it links fine. 
At the time, I presumed that this meant that the pthread stuff was in libc.a.
However, I now realize that compiling in grade asm_fast.gc.par currently does
not enable the use of threads on dec-alpha-osf*, it just changes what
libraries get linked in.  My change makes the above error go away, but results
in link errors when linking programs that do actually use threads.

I managed to narrow the test case down to this:

	$ cat foo.c

	#include <stdlib.h>
	int main() {
		malloc(1);
	}

	$ gcc -static foo.c -lpthread
	... same error message as above ...

So it looks like (a) my change to scripts/ml.in was not correct
and (b) there is a problem with the static pthread libraries on murlibobo.

I suggest you fix (a) by undoing my change to scripts/ml.in.
(b) is not our fault, and for now we can probably just ignore it.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------



More information about the developers mailing list