Problem with shared libraries on Solaris 8

[Stan Guillory]

I have just upgraded to Autoconf 2.59, Automake 1.95, and Libtool
1.5.14. Now when I build shared libraries,
they don't have the .so extension in thier names. Anybody know why? It
may be a question for the libtool list,
but I thought I try both places.

Stan


>>> Hugh Sasse Staff Elec Eng <address@hidden> 3/1/2005 7:39:11 AM >>>
On Tue, 1 Mar 2005, Stepan Kasal wrote:

> Hi,
>  let me formulate a proposal.  I try to be as specific as possible.

Thank you, this is a help (I'm somewhat overloaded at the moemnt).
>
> AC_MSG_NEED(PACKAGE, TEXT)
> ------------------------------
> Prints a message and saves it for later usage.
> Example: AC_MSG_NEED(foo, [grab the latest foo from foo.org])
> prints:
>
> Suggestion:
>  foo          grab the latest foo from foo.org
>
This encapsulates the ideas well,

> AC_MSG_COND_NEED(CONDITION, PACKAGE, TEXT)
> ------------------------------------------
> Prints a message and saves it for later usage.
> Example: AC_MSG_COND_NEED(--with-graphs, libxy,
>       [use the latest xy library from http://www.xylib.net/])
> prints:
>
> Suggestion (for --with-graphs):
>  libxy                use the latest xy library from
http://www.xylib.net/ 
>

and this incorporates requirements information well.
>
> AC_OUTPUT

Maybe call it AC_MSG_OUTPUT to tie it to the other two?
> ---------
> If there were any call to AC_MSG_NEED or AC_MSG_COND_NEED, all the
> suggestions are printed, and then configure exits; it doesn't create
> config.status in this case.
>
> Example:
> Suggestions:
>  foo          grab the latest foo from foo.org
>  bar          grab the latest bar from http://www.barbar.com 
> (for --with-graphs):
>  libxy                use the latest xy library from
http://www.xylib.net/ 
>
> Thats all.  I think implementing this proposal is a good step
forward.

Yes, that is what I was hoping for.
>
> The most difficult part is the documentation, of course.  I don't
> volunteer for it.  Hugh, could you please write a patch to
autoconf.texi,
> which would document these macros, and, most importantly, encouradge
> their usage?

I'm not familiar with the layout of the CVS base, so can you tell me
how to get hold of the file I should be writing the patch against,
please?
>
> I could then add some macros and patch autoconf's own configure.ac.
>
> A few comments:
> Comment #1:
> -----------
> I chose AC_MSG_NEED instead of a combination of AC_MSG_END and
> AS_SUGGEST_STRING.  I think the macro should be as simple as
possible,
> so that mor people use it.

I'm happy with either, as long as something happens.  Are you one of
the maintainers?  (I don't know "who's who" in autoconf, I admit!)
>
> Comment #2:
> -----------
> This proposal doesn't handle dependencies among the requirements.
> This is intentional; I think a maintainer should only specify the
> list of requirements.  Only sysadmins and distribution builders are
> allowed to think about a "dependency tree".

Also there is too much to consider when requesting that change. 
Furthermore, much can be achieved with the existing AS_IF macro, so
I'm happy to let that go for now.  Would it be sensible to allude to
this when I write the doc patch, or just leave dependency matters
out of the discussion?  The critical change here is that failure is
not immediate, and important messages appear at the end where they
are likely to be seen (not lost from the scroll buffer).

> In most cases, we can check for all requirements independently.
> In the rare case when it is impossible to perform a check for "bar"
> if "foo" wasn't found, we can use this pattern:
>
> # check for foo and set have_foo
> if test $have_foo = no; then
>  AC_MSG_NEED(foo, [grab foo from ...])
> fi
> have_bar=no
> if test $have_foo = yes; then
>  # check for bar
>  # and set have_bar appropriately
> fi
> if test $have_bar = no; then
>  AC_MSG_NEED(bar, [grab bar from ...])
> fi

Sounds reasonable, or one could use AS_IF.
>
> Hugh, are you willing to work on this proposal, and make a patch to
> autoconf.texi?

Yes, I'll try to put something together, but it will probably need
to be reviewed as I'm not familiar enough with the use and abuse of
autoconf.
>
> Stepan
>
         Thank you,
         Hugh


_______________________________________________
Autoconf mailing list
address@hidden 
http://lists.gnu.org/mailman/listinfo/autoconf