This is the mail archive of the
gsl-discuss@sources.redhat.com
mailing list for the GSL project.
Re: gsl on macos x
- To: Jeff Whitaker <jsw at cdc dot noaa dot gov>
- Subject: Re: gsl on macos x
- From: Brian Gough <bjg at network-theory dot co dot uk>
- Date: Mon, 9 Jul 2001 16:27:12 +0100 (BST)
- Cc: <gsl-discuss at sources dot redhat dot com>
- References: <15177.32483.121348.670676@debian><Pine.OSX.4.33.0107090601320.11512-101000@localhost.cdc.noaa.gov>
Jeff Whitaker writes:
> That said, even dyld is able to handle some conflicts. Otherwise it
> wouldn't be possible to link a program against libncurses, for
> example. Since the libraries are (hopefully) loaded in a
> deterministic order, this at least doesn't produce "heisenbugs". With
> dynamic loading the checks have to be more strict as the load order
> may differ from one program run to another. dyld also doesn't allow
> duplicate symbols when generating a shared library that depends on
> other shared libraries; this is again related to load order (I think).
The only thing I can suggest is, using the CVS version, to try
rearranging the order of SUBLIBS libraries in the top-level
Makefile.am
Currently they are in alphabetical order(!), so putting them in load
order might help. For example, libgslblock should be after
libgslvector in load order. You could try putting libgslblock after
libgslvector and see if that reduces the number of errors.
However, the log shows that the linker also complains about functions
like gsl_ran_bernoulli, which is not used anywhere else in the library
so this might not help because load order should not be an issue
there.