Building Fortran 77 libtool modules

ltmain.sh (GNU libtool) 1.5 (1.1220 2003/04/05 19:32:58) automake (GNU automake) 1.8 Hi, I want to create a libtool module written in Fortran 77 and ended up with the following code: $ cat configure.ac AC_INIT([foo], [1.0], [EMAIL PROTECTED]) AM_INIT_AUTOMAKE([1.7 foreign no-define]) AC_CONFIG_

Re: Problem porting linux shared library to windows using cygwin and libtool

Hi Thomas, if you wish to create Matlab MEX-Files using the GNU build environment, check out http://home.allgaeu.org/rschleic/rs/pub/mextool/mextool-2.0.tar.gz and http://home.allgaeu.org/rschleic/rs/pub/m-config/m-config-4.0.tar.gz I wrote the tools for porting Matlab stuff to MSYS/MinGW. A f

RE: Forcing shared libaries

Sander Niemeijer writes: > Ralph Schleicher already provided a patch to libtool for such a > feature, but I don't know the current status of this patch (whether it > will be in the next libtool release or not; anyone???). Got a mail from Gary yesterday. He applied my patch to HEAD. Hip hip hurra

Re: Installing in a staging area

Sander Niemeijer writes: > Why not use a 'make DESTDIR=/usr/local/staging/appname install'? I installed my staged packages like that, but the error remains. Please note that 'make DESTDIR=/foo install' works well for native builds, but not within a cross-compilation environment. I'm quite confid

Re: Installing in a staging area

Charles Gagnon writes: > I am having a hard time installing apps in a staging area. What I am > trying to do is this: > > ./configure --prefix=/usr/local > make > make prefix=/usr/local/staging/appname install > > The purpose is to package everything in /usr/local/staging/appname > to be later i

RE: Building .so files only.

Tom Howard writes: > That's my point. My understanding of Stephen problem is that he doesn't want > to build/install the companion files. [...] > So in his situation, patching libtool and using -shared isn't really going to > solve his problem. Correct? As already pointed out by Daniel Reed, -a

RE: Building .so files only.

Tom Howard writes: > Sorry if I'm being dense, but (after reading the referenced messages) I don't > understand why using the -shared flag will only produce the a .so file. > Won't it still produce a .so.X, .so.X.X.X and .la files as well? In libtool jargon, ".so file" is a synonym for a shared l

RE: Building .so files only.

Stephen Torri writes: > So by patching my libtool I should be able to put the -shared flag in my > AM_LDFLAGS for the Makefile.am and only get the shared.so file right? Yes, but it makes sense adding it to CFLAGS, too. > ! If the @samp{-static} option is given, then only a @samp{.o} file is > !

Re: Building .so files only.

See , for more details. -- Ralph ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool 1.5 on hppa2.0-hp-hpux10.20

Steve Edwards writes: > (Warning) At least one PA 2.0 object file (conftest.o) was detected. > The linked output may not run on a PA 1.x system. Add LDOPTS='+vnocompatwarnings +s' export LDOPTS to your .profile file. -- Ralph ___ Libtoo

Re: Request for option to disable building of static library

albert chin writes: > Anyone available to review this patch? I'll take the action. -- Ralph ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: Request for option to disable building of static library

Howard Chu writes: > I've requested this feature and sent patches for it at least twice over the > past 3 years. The first time was silently ignored, the second rejected. I submitted a patch on 2003-02-10 for the upcomming Libtool 1.5 release but it was silently ignored, too. -- Ralph _

Libtool dependency_libs vs. cross-compiling

ltmain.sh (GNU libtool) 1.4e (1.1192 2003/02/18 05:15:03) Hi, I'm cross-compiling a whole system (MinGW + extensions) on a HP-UX box. All packages are configured with --prefix=/sys and installed via `make prefix=/prefix/sys'. My intention is to do a '(cd /prefix/sys && tar cf ../sys.tar .)' to

Re: possible bug in install mode for Libtool modules

Wesley W. Terpstra wrote: > Line them up ---^ Uups, thank you. -- Ralph ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

possible bug in install mode for Libtool modules

ltmain.sh (GNU libtool) 1.4e (1.1192 2003/02/18 05:15:03) Hi, I'm cross compiling Libtool modules for a MinGW host on a HP-UX box. When running 'make install', I get a strange error message: /bin/sh ../../libtool --mode=install /home/raid/cea_adm/hppa2.0w-hp-hpux11.00/bin/install -c cof_0102.la

Re: bug in libtool --mode=install with EXEEXT

Sebastien Sable wrote: > ../libtool: line 5764: ./test_libbraille.: No such file or directory Hi, just ran in the same bug while cross compiling for MinGW on a HP-UX box. Here is a patch: 2003-02-27 Ralph Schleicher <[EMAIL PROTECTED]> * ltmain.in: Only append a dot to the wrapper

Re: Check for ar (libtool bug)

Robert Boehne wrote: > Typically we define things to ":" when they are not found. Hi Robert, $ grep AC_CHECK_TOOL libtool.m4 AC_CHECK_TOOL(RANLIB, ranlib, :) AC_CHECK_TOOL(STRIP, strip, :) AC_CHECK_TOOL(DLLTOOL, dlltool, false) AC_CHECK_TOOL(AS, as, false) AC_CHECK_TOOL(OBJDUMP, objdump, f

Check for ar (libtool bug)

Hi, libtool does not explicitly check for 'ar'. If no other Autoconf command checks for 'ar' before AC_PROG_LIBTOOL is processed, then libtool uses AR=ar which fails when cross compiling. Here is a patch against libtool CVS together with a ChangeLog entry. 2003-02-20 Ralph Schleicher <[EMAIL

Re: Pending release of 1.5

Robert Boehne wrote: > I'm just about to make the release of Libtool 1.5. If anyone would > like to test the current CVS on their favorite platform and report > any problems, please do so! If not, your woes may have to wait for > 1.5.1. Here is yet another feature for libtool 1.5. I've already

Re: Pending release of 1.5

Robert Boehne wrote: > Yes, that would be fine. > "Schleicher Ralph (LLI)" wrote: > > My original patch required to explicitly add a dot. Do you accept a > > patch that restores the original behavior? I've attached the patch to this message. Here is the Cha

Re: Pending release of 1.5

Robert Boehne wrote: > I'm just about to make the release of Libtool 1.5. If anyone would > like to test the current CVS on their favorite platform and report > any problems, please do so! If not, your woes may have to wait for > 1.5.1. The new option -shrext implies a leading dot for the shar

patches for building loadable modules

libtool 1.4.2 Hi, here is a patch for Libtool for more control about how libraries (especially loadable modules) are compiled and linked. First, a -no-static option is added to (a) not compile static object files and (b) not create static libtool libraries. Second, a -soext option is added to

Re: Libtool misfeature on HP-UX

Albert Chin <[EMAIL PROTECTED]> writes: > Please post it to this list. I tried your example on a sample project > here and it seemed OK. I don't have a patch for libtool though. If I > have time, I'll try to do it but time is scarce these days. Okay, here it is. foobar.tar.gz Description: fo

Re: Libtool misfeature on HP-UX

Albert Chin <[EMAIL PROTECTED]> writes: > Hmm, this seems like a positive. Does it have any side affects? Have > you made this change and run the test suite against it? I don't think it has any side effects. I tried to patch Libtool but I didn't manage it completely. Adding for i in \$deplibs

Re: Libtool misfeature on HP-UX

"Boehne, Robert" <[EMAIL PROTECTED]> writes: Hi Robert, > I would expect Libtool to translate "libfoo.la" to "libfoo.${ext}" > and to translate -lfoo into -lfoo, perhaps you should put "-lfoo" > in _LDFLAGS instead of libfoo.la. But "-lfoo" is not sufficient when linking against a non-installed

Libtool misfeature on HP-UX

ltmain.sh (GNU libtool) 1.4.2 (1.922.2.54 2001/09/11 03:33:37) Hi, I encountered a problem with Libtool libraries on HP-UX. Consider the following (simplified) Makefile.am: lib_LTLIBRARIES = libfoo.la libbar.la libfoo_la_SOURCES = foo.c libbar_la_SOURCES = bar.c libbar_la_LDF

Re: libtool and JNI libraries on Mac OS X

Don Anderson <[EMAIL PROTECTED]> writes: > I was of a libtool option: > >--moduleext=.jnilib Hi, I second that. I'm experimenting building Matlab MEX-files using Libtool and run into the same problem. At present, my Makefile.am looks as follows: -