answers!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
on distributing shared libraries in binary would be most
appreciated. Most of our users have downloaded the binaries rather
than building from source, and we would like to be able to continue
doing that, if possible.
Thanks!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED
in this situation? That is, is
there any time on the users machine that the linker notices that he is
now linking to 1.0.0 instead of 0.0.0?
Thanks!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
Bob Friesenhahn [EMAIL PROTECTED] writes:
On Fri, 13 May 2005, Ed Hartnett wrote:
How does the version number get used in this situation? That is, is
there any time on the users machine that the linker notices that he is
now linking to 1.0.0 instead of 0.0.0?
Yes, the linker notices
question consider that most scientists
wouldn't really care all that much about exploding computers, as long
as the data files were not corrupted.
Thanks, your explanations are really clearing the mists around
libtool!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED
Daniel Reed [EMAIL PROTECTED] writes:
On Fri, 13 May 2005, Ed Hartnett wrote:
Bob Friesenhahn [EMAIL PROTECTED] writes:
Yes. Unless it is explicitly deleted.
Suppose that we discover a bug which doesn't require any API change to
fix, but which will cause he users' computers to go into self
Bob Friesenhahn [EMAIL PROTECTED] writes:
On Fri, 13 May 2005, Ed Hartnett wrote:
How does the version number get used in this situation? That is, is
there any time on the users machine that the linker notices that he is
now linking to 1.0.0 instead of 0.0.0?
Yes, the linker notices
be most helpful. I'm used to
getting one file: netcdf.dll - did I get something here that I can use
just by dropping it into a directory and then using a M$ IDE to
program with the DLL?
Thanks!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http
of the flesh, and the difficulty of maintaining (and
testing) multiple build environments.
Thanks!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
:163: required file `config/ltmain.sh' not found
autoreconf: automake failed with exit status: 1
bash-2.05b$
Any thoughts on this?
Thanks!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
Bob Friesenhahn [EMAIL PROTECTED] writes:
On Fri, 20 May 2005, Ed Hartnett wrote:
The command works if I use --tag=f77 as a libtool option, but where in
my automake files can I specify a libtool option like --tag=f77?
Is there some way to specify libtool parameters like --tag
distribution: 1.5.18, and reasonably
recent versions of autoconf and automake.
Please tell me I haven't done all this libtool conversion for
nothing. If I can't get our package to build on the Sun, I can't use
libtool.
Can anyone help?
Thanks!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED
do you use F77=f95 or do you use both f77 and f95 in your package?
OK, this all turned out to be an automake version problem after all.
Once I had all machines using version 1.9.5 of automake, this went
away.
Thanks for the help!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED
in a way
that was sensible in the libtool universe.
Thanks,
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
of gnu.org[1], we will now enable moderation for all
non-member posts, for all of the libtool lists[2], in accordance with
maintainers best practices[3].
Great work Ralf!
Thanks for all the hard work you do!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED
pgf90 epcf90 g77])
So here I call first AC_PROG_F77, then AC_PROG_FC.
If I just call AC_PROG_FC, the later, when I call AC_PROG_LIBTOOL it
will call AC_PROG_F77, ignoring the fact that FC is set to the fortran
compiler.
Is there a better way to handle this?
Thanks!
Ed
--
Ed Hartnett
Howdy all!
If I use libtool, I seem to get bash scripts. Does this mean my users
must have bash installed?
Thanks!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
be wonderful!
Thanks!
Ed
PS - I'm using libtool version 1.9f.
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
can't find
documentation of LTFCCOMPILE - is there an equivilant for linking?
This is with libtool 1.9f, BTW.
Thanks for any suggestions!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
: `/home/ed/local/shecky/share/aclocal/ltoptions.m4'
libtoolize: `/home/ed/local/shecky/share/aclocal/ltversion.m4'
libtoolize: `/home/ed/local/shecky/share/aclocal/ltsugar.m4'
libtoolize: `/home/ed/local/shecky/share/aclocal/lt~obsolete.m4'
WHat is the deal with this?
Thanks!
Ed
--
Ed
Gary V. Vaughan [EMAIL PROTECTED] writes:
Ed Hartnett wrote:
Howdy all!
I got the latest libtool from the CVS and installed it. Now when I
build my library, I get the following error:
libtool: Version mismatch error. This is libtool 2.1a, but the
libtool: definition of this LT_INIT
[1]: *** [libnetcdf_c++.la] Error 1
make[1]: Leaving directory `/shecky/n3_new2/cxx'
make: *** [check-recursive] Error 1
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
Ralf Wildenhues [EMAIL PROTECTED] writes:
Hi Ed,
* Ed Hartnett wrote on Fri, May 05, 2006 at 09:30:02PM CEST:
Ralf Wildenhues [EMAIL PROTECTED] writes:
* Ed Hartnett wrote on Fri, May 05, 2006 at 02:43:42PM CEST:
Building my package with libtool, I get the following error on my
linux
deleted.
I reinstalled libtool and automake, and rebuilt everything, and the
problem disappeared.
Thanks!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
that it was possible to generate dlls
which either did or did not depend on the cygwin dll being present on
the machine. True?
Thanks for any info!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
. Does anyone have an easy
answer for me?
Thanks!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
$
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
Keith MARSHALL [EMAIL PROTECTED] writes:
Ed Hartnett wrote:
When attempting to do a mingw cross-compile, the configure script
checks for a whole bunch of extra compilers. What's up with that?
If I do this:
bash-3.1$ ./configure --host=i686-pc-mingw32 --build=i686-pc-cygwin
--disable-f90
it.
My question is: when it comes to libraries, does size matter?
Any thoughts appreciated. Thanks.
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
copy of the foo() functions.
More information on shared libraries can be found at the following
external sites:
* The Program-Library HowTo, by David Wheeler.
* Wikipedia Library Entry
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http
to be changed in a
compiler-dependent way! (Which means each and every user would email
me and ask me how to do it for their compiler!)
Hopefully I am missing something here?
Thanks,
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman
economy will make up for any performance
penalties. Shared libraries do offer dramatic maintenance advantages; for a
significant amount of code, that justifies the performance ambiguity.
Thanks, this is very helpful.
I knew my explanation was naive! I will update my FAQ...
Thanks again!
Ed
--
Ed
libraries which have switched to libtool handled this
transition?
Thanks,
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
yet, but I
suppose it could be solved at the same time as the inter-makefile
library-installation-order issue is solved.
Well, no need to get too fancy.
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
/lib/crt2.o(.text+0x2c0):crt1.c: first defined here
Thanks!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
Ralf Wildenhues [EMAIL PROTECTED] writes:
Hello Ed,
* Ed Hartnett wrote on Tue, Dec 05, 2006 at 12:43:25AM CET:
I am having a lot of trouble building my library with libtool under
mingw. I keep getting these errors relating to atexit. Can anyone
enlighten me as to what that is?
libtool
Ed Hartnett [EMAIL PROTECTED] writes:
libtool: link: gcc -g -O2 -o .libs/t_nc.exe t_nc-t_nc.o
./.libs/libnetcdf.lib -L/usr/local/lib
Another clue - everything works if I change the above to:
gcc -g -O2 -o .libs/t_nc.exe t_nc-t_nc.o ./.libs/libnetcdf-0.dll
-L/usr/local/lib
That is, it's
Ralf Wildenhues [EMAIL PROTECTED] writes:
* Ed Hartnett wrote on Thu, Dec 07, 2006 at 01:52:11PM CET:
libtool: link: gcc -g -O2 -o .libs/t_nc.exe t_nc-t_nc.o
./.libs/libnetcdf.lib -L/usr/local/lib
Another clue - everything works if I change the above to:
gcc -g -O2 -o .libs/t_nc.exe
Wildenhues for the
patches, and all the autotools help in general!)
Thanks Ralf!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
not be called again?
Thanks!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
Ralf Wildenhues [EMAIL PROTECTED] writes:
* Mike Frysinger wrote on Tue, Jan 16, 2007 at 11:48:31PM CET:
On Tuesday 16 January 2007 17:30, Ed Hartnett wrote:
When I call AC_PROG_LIBTOOL it seems to call AC_PROG_F77 and
AC_PROG_FC, but I don't want it to.
this should be fixed
Ralf Wildenhues [EMAIL PROTECTED] writes:
Hello Ed,
* Ed Hartnett wrote on Wed, Jan 03, 2007 at 05:50:38PM CET:
On our HPUX platform however, no libnetcdf.so file results. Yet the
build seems to work OK.
The shared library extension should be '.sl'. Please show
./libtool --config
Ralf Wildenhues [EMAIL PROTECTED] writes:
* Ed Hartnett wrote on Fri, Jan 19, 2007 at 03:02:01AM CET:
Ralf Wildenhues [EMAIL PROTECTED] writes:
* Ed Hartnett wrote on Wed, Jan 03, 2007 at 05:50:38PM CET:
On our HPUX platform however, no libnetcdf.so file results. Yet the
build seems
Ralf Wildenhues [EMAIL PROTECTED] writes:
* Ed Hartnett wrote on Mon, Jan 22, 2007 at 09:31:36PM CET:
I only have this one HPUX system to test on, and it's pretty out of
date, I suspect. But if I ask them to upgrade it, they'll probably
just say Nah, let's just get rid of it...
Do you
warn about portability when linking against -modules?
shouldnotlink=no
# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''
# Directory that this library needs to be installed in:
libdir='/usr/local/lib'
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http
Ralf Wildenhues [EMAIL PROTECTED] writes:
Hello Ed,
* Ed Hartnett wrote on Fri, Dec 08, 2006 at 03:12:34AM CET:
This must have been a Nd problem. When I upgraded to gcc 3.4.2
the whole problem went away.
Hmm, that still worries me, plus I'm not sure what Nd means;
is that similar
.
Thanks!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
? I don't construct the aclocal.m4 file
anyway. I have an acinclude.m4 file...
Is this a harmless warning or is there a serious problem here?
Thanks!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
with the SUNW compilers.
Only the shared SUNW build is a problem.
If anyone could shed some light on this problem, that would be greatly
appreciated!
Thanks!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
Dan Nicholson [EMAIL PROTECTED] writes:
On Tue, Apr 22, 2008 at 4:24 AM, Ed Hartnett [EMAIL PROTECTED] wrote:
Howdy all!
Firstly, thanks for developing libtool! It's really helpful!
I am using it to distribute a freeware scientific data library,
netcdf. The netcdf distribution actually
/DUDLEY/lib/libhdf5.la' was moved.
libtool: link: warning: library
`/upc/share/ed/local/DUDLEY/lib/libhdf5_hl.la' was moved.
libtool: link: warning: library
`/upc/share/ed/local/DUDLEY/lib/libhdf5.la' was moved.
--
Ed Hartnett -- [EMAIL PROTECTED
Bob Friesenhahn [EMAIL PROTECTED] writes:
On Mon, 5 May 2008, Ed Hartnett wrote:
Howdy all!
Sometimes I get these warnings (see below), and I don't really get
what libtool is trying to tell me...
It means that your hdf5 library was originally installed into a
different directory path
help would be appreciated.
Thanks!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
the problem of installing only the static
library.
(The .a file is always a static library, right?)
Thanks,
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
working fine, but
in the end installing only a .a file.
Perhaps intel compilers also package their shared libraries in .a
files...
I know that macs use .dylib, HPs use .sl, (and I thought CYGWIN used
.lib, but I may be wrong there).
Thanks,
Ed
--
Ed Hartnett -- [EMAIL PROTECTED
Segmentation fault(coredump)
Is this expected? Or should I be able to build shared libraries with
version 3.2 of g++ and g77?
Thanks!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
Bob Friesenhahn [EMAIL PROTECTED] writes:
On Tue, 13 May 2008, Ed Hartnett wrote:
I am the maintainer for a freeware scientific software library called
netcdf. There are C, Fortran, and C++ libraries.
When building shared libraries with older versions of the tools, I get
problems. gcc
Bob Friesenhahn [EMAIL PROTECTED] writes:
On Wed, 14 May 2008, Ed Hartnett wrote:
Is this expected? Or should I be able to build shared libraries with
version 3.2 of g++ and g77?
You have not given much to go on here. Are you sure that your
software doesn't have a bug? Maybe you should
])
LT_INIT()
AC_SUBST(ARFLAGS, [$ARFLAGS])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT()
Makefile.am:
AM_ARFLAGS = $(ARFLAGS)
lib_LTLIBRARIES = libsmall.la
libsmall_la_SOURCES = small.c
small.c:
int
fun()
{
return 42;
}
--
Ed Hartnett -- [EMAIL PROTECTED
though...
Cheers,
Peter
Ah ha!
Thank you Peter. That works.
I will hit the sauna and stop by Old Chicago on the Perl St. Mall and
see what they have in the way of Swedish beer. If you were here, I
would buy you one, but since you are not, I will buy myself one! ;-)
Ed
--
Ed Hartnett
Bob Friesenhahn [EMAIL PROTECTED] writes:
On Wed, 21 May 2008, Ed Hartnett wrote:
From the info pages on Automake:
`AR' and `ARFLAGS' default to `ar' and `cru' respectively; you can
override these two variables my setting them in your `Makefile.am',
by `AC_SUBST'ing them from your
file_system_path] [-all_load] [-noall_load]
make[2]: *** [libnetcdff.la] Error 1
make[1]: *** [check] Error 2
make: *** [check-recursive] Error 1
Am I doing something wrong here?
Thanks,
Ed
--
Ed Hartnett -- e...@unidata.ucar.edu
___
http://lists.gnu.org
Peter O'Gorman pe...@pogma.com writes:
On 01/07/2011 06:30 AM, Ed Hartnett wrote:
libtool: link: g95 -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o
.libs/libnetcdff.0.dylib .libs/fort-attio.o .libs/fort-control.o
.libs/fort-dim.o .libs/fort-genatt.o .libs/fort-geninq.o
/netcdf/trunk/nc_test/util.c:273: undefined reference to `floor'
collect2: ld returned 1 exit status
As I read the above, when make calles libtool, it has the -lm, but when
libtool calls gcc, the -lm is missing.
Any idea what I might be doing wrong here?
Thanks,
Ed
--
Ed Hartnett -- e
Howdy all!
I have found the reason for this problem - I did not correctly specify
the target!
Thanks,
Ed
--
Ed Hartnett -- e...@unidata.ucar.edu
___
https://lists.gnu.org/mailman/listinfo/libtool
-snapshot2011051306/fortran'
make[1]: *** [install] Error 2
make[1]: Leaving directory
/data/gerry/apps/netcdf-4.1.3-rc1-snapshot2011051306/fortran'
make: *** [install-recursive] Error 1
--
Ed Hartnett -- e...@unidata.ucar.edu
___
https://lists.gnu.org
yet, but I
suppose it could be solved at the same time as the inter-makefile
library-installation-order issue is solved.
Well, no need to get too fancy.
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http
69 matches
Mail list logo