About a month ago there was some discussion on the automake list about the
possibility of supplementing "make install" with something along the lines
of a "make pkg": the aim being to be able to produce a OS-type package
(RPM, Solaris pkg, etc.) for subsequent installation. (A copy of the
initi
> "David" == David Lee <[EMAIL PROTECTED]> writes:
David> But any such project would, I think, have a "libtool"
David> interaction, and I know almost nothing about the insides of
David> libtool. It would seem to require a variant of "libtool
David> --mode=install" that doesn't actually do th
I am trying to use libtool (along w/ automake/autoconf) to build a .sl
(on HPUX 10.20) that is a dynamically-loaded perl module, and I'm
running into a few problems.
First, my Makefile.am:
--
perllib_DATA = swigShapeUtils.pm
perllibarch_LTLIBRARIES
On 14 Feb 2001, Tom Tromey wrote:
> > "David" == David Lee <[EMAIL PROTECTED]> writes:
>
> David> But any such project would, I think, have a "libtool"
> David> interaction, and I know almost nothing about the insides of
> David> libtool. It would seem to require a variant of "libtool
> Dav
In message <[EMAIL PROTECTED]>,
David Lee writes:
>But the "big picture" is to be able to produce something along the lines of:
>
> # Directories...
> $prefix=/usr
>[...]
>
> # Installables
> %system all
> f 0555 root sys ${libdir}/libgdbm.so.2.0.0 .libs/libgdbm.so.2.0.0
> l 0555 root
> "Jeremy" == Jeremy Slade <[EMAIL PROTECTED]> writes:
Jeremy> What I really want to build is 'swigShapeUtils.sl', which
Jeremy> corresponds to the swigShapeUtils.pm module. But automake
Jeremy> complains:
Jeremy> automake: src/perl/swig/Makefile.am: `swigShapeUtils.la' is not a
Jeremy> sta
Tom Tromey writes:
> > "Jeremy" == Jeremy Slade <[EMAIL PROTECTED]> writes:
>
> Jeremy> What I really want to build is 'swigShapeUtils.sl', which
> Jeremy> corresponds to the swigShapeUtils.pm module. But automake
> Jeremy> complains:
>
> Jeremy> automake: src/perl/swig/Makefile.am: `swigS
Under AIX 4.3.3 w/ g++ 2.95.2 I have a problem with libraries
that depend on other libraries. Everything works if I explicitly
add every dependent library to Makefile.am, but it should
be working auto-magically. The following is linker command output
by libtool in an attempt to create an unistal
Braden McDaniel wrote:
>
> Is it possible to statically link against a helper library? The output of
> the process needs to be a shared library, so configuring with
> AM_DISABLE_SHARED isn't the answer. And I don't want to just include the
> objects in the helper lib in the shared lib, as I don't
On Wed, 14 Feb 2001, Robert Boehne wrote:
> Braden McDaniel wrote:
> >
> > Is it possible to statically link against a helper library? The output of
> > the process needs to be a shared library, so configuring with
> > AM_DISABLE_SHARED isn't the answer. And I don't want to just include the
> > o
On Feb 14, 2001, David Lee <[EMAIL PROTECTED]> wrote:
> As I say, I'm floundering, and may be overlooking something obvious.
For one, the fact that libtool may have to relink libraries and/or
executables at installation time. Of course, you might include all
the dependence libraries and object-
On Tue, Feb 06, 2001 at 09:12:12PM -0600, Sam TH wrote:
> On Wed, Feb 07, 2001 at 01:02:52AM -0200, Alexandre Oliva wrote:
> > On Feb 6, 2001, Sam TH <[EMAIL PROTECTED]> wrote:
> >
> > > /bin/sh ../../libtool --mode-link c++ -o foo lib1.la lib2.la lib1.la \
> > > lib2.la lib1.la lib2.la
> >
> >
On Feb 14, 2001, Jeremy Slade <[EMAIL PROTECTED]> wrote:
> It seems that what I really what is to create swigShapeUtils.sl
> using the original ../../lib/*.lo files build earlier (and used to
> create libShapeUtils.sl), rather than create swigShapeUtils.sl with
> a run-time dependency on libShape
13 matches
Mail list logo
