[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2 non-libtool libs want to start

From: Ross Boylan
Subject: Re: 2 non-libtool libs want to start
Date: Fri, 10 Dec 2004 11:10:59 -0800
User-agent: Mutt/1.5.6+20040722i

On Fri, Dec 10, 2004 at 08:57:27AM +0100, Ralf Wildenhues wrote:
> * Ross Boylan wrote on Thu, Dec 09, 2004 at 09:22:34PM CET:
> > I have two libraries, both of which want to be the one that starts.  I
> > assume they both define main, though I have not verified that.  Both are
> > 3rd party, non-libtool, libraries.
> The C `main' function is defined in these libraries?  Please verify
> this (use nm or objdump or whatever libtool uses as $NM).

I verified with nm that both the R and boost test libraries define
(not just refer to) the symbol _main.

It is very puzzling that the R library defines main, since the
documentation implies that it is up to the user of the library to do
startup.  I've now seen this on two different platforms, so it's not
just a quirk of an individual build of the R library.  I have a
query in to the R list about this.

> I really don't know if this works portably.
I'm stunned it works at all.  For example, the documentation on the
loader on OS X seems to imply it will barf on doubly defined symbols.
That perhaps refers to double definitions within a single module.  The
fact that one of the libs is dynamically loaded (R) may be a factor.

Also, OS X has what they call a "double namespace" in which symbols
are defined within the context of a particular library.
> > Second, is there any kind of general help libtool can offer for this
> > problem?  On Linux, fiddling with the order of the libraries on the link
> > line was adequate to control which one got control.  I am porting to
> > Apple's OS-X, and have not been so fortunate there.
> Could you be more specific?  What did you do and what happened?
The problem was that initially when I started the test program it
immediately began executing R--it typed the usual R intro message, then
presented a prompt, and responded to input as R does.  Alternately, if
started without the environment variables R needs, it would issue a
warning and fail.

On linux, when I changed the order of the libs, the boost test suite
took control and ran all the tests I had specified.  That was the
behavior I wanted.

> The best thing would be to provide a small test example.  We could put
> that in libtool's test suite and let exposure show if it works on other
> platforms.

The R library itself is large and complicated, though if the issue is
multiple mains it would probably be possible to make a small test.
But would that be advisable?  Multiple mains seems like something that
shouldn't work and you shouldn't do, despite my having stumbled into

I was thinking there might be a way of specifying where the code
starts.  However, since I haven't found it in the docs to the OS X
loader, it seems unlikely libtool could provide such a facility.  But
I may have missed something.

I have somewhat worked around this by providing a dummy R library that
defines the one function I call and does not have a main.

This is only somewhat a solution because I wanted to run my test
against the actual shared library that R builds when it makes my stuff
into a package.  That shared library links to the real libR, so at the
moment I'm unable to test it.  I can test static builds.

> Regards,
> Ralf

reply via email to

[Prev in Thread] Current Thread [Next in Thread]