Hi Peter,
On 24 Oct 2011, at 08:29, Peter O'Gorman wrote:
On 10/23/2011 08:24 PM, Gary V. Vaughan wrote:
My bad... I've been away from libtool development so long that I totally
forgot to
differentiate between bug-libtool and libtool-patches. Sorry about that.
One day I'm going to have
On Thursday, October 20, 2011 11:07:13 PM Roumen Petrov wrote:
Hi Andreas and Bo,
Please could you clarify build of 64-bit system for 32 bit.
Hi Roumen,
Roumen Petrov wrote:
Hello All,
I wonder how to build and test on a 64 bit platform a 32 bit libtool
version.
First test
Hi Andreas and Bo,
Please could you clarify build of 64-bit system for 32 bit.
Roumen Petrov wrote:
Hello All,
I wonder how to build and test on a 64 bit platform a 32 bit libtool
version.
First test is to use --build=x86_64-gnu-linux --host=i386-gnu-linux
with CC and CXX set to 'gcc|g
Hello All,
I wonder how to build and test on a 64 bit platform a 32 bit libtool
version.
First test is to use --build=x86_64-gnu-linux --host=i386-gnu-linux with
CC and CXX set to 'gcc|g++ -m32', i.e. multilib .
The libtool regression suite fail in test case :
25: duplicate convenience
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The annotated tag, v2.4.2 has been created
at 91c99165d9cbdd14569f046eb586c67020dd1045 (tag)
tagging
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via e9efe2cf60837796f03132ca3c2cf2f53193e619 (commit)
via
Libtoolers!
The Libtool Team is pleased to announce the release of GNU Libtool 2.4.2.
GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl, which
hides the complexity of loading dynamic runtime libraries (modules
Hi Gary,
Extreme nits follows, you have been warned...
Cheers,
Peter
Gary V. Vaughan skrev 2011-10-17 07:42:
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch
I suppose. I'll fix and commit, thanks.
I think that it is best to include this sort of comment in the libtool
TODO file similar to other tasks which are left to do rather than
spamming the script with duplicated comments. Certainly no more than
one comment near the point of first usage
Hi Peter
I have tried using just g++ (no libtool) and the link succeeds. On this
occasion it seems easiest for me just not to use libtool.
Thanks for your help and advice.
Best regards
David
___
https://lists.gnu.org/mailman/listinfo/libtool
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 789817d512111d063981446efc7493ce87696bb3 (commit)
from
Hi
I am using libtool in a makefile to create a shared library containing my
application code, which also links to wxWidgets libraries. As a consequence of
changing both platform (including gcc version) and wxWidgets packages, my
makefile ceases to work. It seems that the libtool command
Hi
I am using libtool in a makefile to create a shared library containing my
application code, which also links to wxWidgets libraries. As a consequence of
changing both platform (including gcc version) and wxWidgets packages, my
makefile ceases to work. It seems that the libtool command
Hi
I am using libtool in a makefile to create a shared library containing my
application code, which also links to wxWidgets libraries. As a consequence of
changing both platform (including gcc version) and wxWidgets packages, my
makefile ceases to work. It seems that the libtool command
On 10/14/2011 02:10 AM, David Aldrich wrote:
Hi
I am using libtool in a makefile to create a shared library containing my
application code, which also links to wxWidgets libraries. As a consequence of
changing both platform (including gcc version) and wxWidgets packages, my
makefile ceases
Hi Peter
Thanks for your reply.
-shared is not a libtool flag
Oh, that's weird! We've been using that option for building other shared
libraries for a long time.
does it work if you do:
libtool --mode=link g++ -o libGUI.la object files -rpath /usr/local/lib
That doesn't work
On 10/14/2011 08:45 AM, David Aldrich wrote:
Hi Peter
Thanks for your reply.
-shared is not a libtool flag
Oh, that's weird! We've been using that option for building other shared
libraries for a long time.
Yes, and older libtools used to pass it along to the compiler driver, so
Your object files are created without using libtool?
Yes, just g++.
ln: creating symbolic link `libGUI.so.0': Operation not supported
make: *** [libGUI.so] Error 1
That's a new one for me, you snipped the ln command that fails though.
I don't know how much you care about portability
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 49ae2888b43cad358e2ff60a69722341116e7b40 (commit)
from
libtoolize to
libtool.
I pushed this patch on Saturday.
Dave, I've attached an approximation of what the patch would do to gcc's
ltmain.sh and an addition to boehm-gc's .exp file. Both completely
untested, of course :-)
Thanks,
Peter
Index: ltmain.sh
On 5-Sep-11, at 12:08 PM, Peter O'Gorman wrote:
I pushed this patch on Saturday.
Thanks.
Dave, I've attached an approximation of what the patch would do to
gcc's ltmain.sh and an addition to boehm-gc's .exp file. Both
completely untested, of course :-)
I'll give this patch a try in
Dear developers,
Is there a plan to release GNU Libtool under GPLv3 or later?
Ralf seemed to say so in his post from 2008 at
https://lists.gnu.org/archive/html/libtool/2008-02/msg00069.html:
Well, yes, eventually we will switch the various differently-licensed
parts of Libtool
On Mon, 29 Aug 2011, Peter O'Gorman wrote:
This turns off warnings for --silent (and turns them on again for --verbose).
But I am not sure that --silent was meant to imply no warnings, rather it
turns off the verbose compile/link messages.
Would a new --no-warnings option be more
handled the same so that the person
building the software can easily decide if the build should be silent.
Hi Bob,
Well, it has to be an option that Dave can add to site.exp for the
failing tests in gcc. The tests are failing on HP-UX because libtool is
outputing this platform does not like
wrote:
The attached patch fixes the boehm-gc testsuite on hppa2.0w-hp-hpux11.11.
Without it, libtool always generates an informational warning when
linking
causing the entire boehm-gc testsuite to fail.
Ok? Ralf would you please install in libtool tree if ok.
2011-07-09 John David Anglin dave.ang
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, libtool-next has been updated
via 27b3a20a7e3a0157b5109383ba6ff2cc16287358 (commit)
via
runtime
search path on some systems (it definitely gets an issue with
AC_RUN_IFELSE)
Fortunately, there is an easy way: One can just duplicate Autoconf's
languages (as being defined by AC_LANG_DEFINE) and modify its $ac_link
to use libtool. I've written an AC macro for this: LT_LTLIZE_LANG.
Of course
The attached patch fixes the boehm-gc testsuite on hppa2.0w-hp-hpux11.11.
Without it, libtool always generates an informational warning when linking
causing the entire boehm-gc testsuite to fail.
Ok? Ralf would you please install in libtool tree if ok.
2011-07-09 John David Anglin dave.ang
(and --enable-shared) to error out if it is not
PR possible to create a shared library (due to a missing -no-undefined).
Sorry for the delay, I got distracted by other things but here is finally
the promised trivial patch (I also cc it to libtool-patches just in case,
sorry if you get this message
(and --enable-shared) to error out if it is not
PR possible to create a shared library (due to a missing -no-undefined).
Sorry for the delay, I got distracted by other things but here is finally
the promised trivial patch (I also cc it to libtool-patches just in case,
sorry if you get this message
On 07/06/2011 01:54 AM, ScottLadd wrote:
I've been writing configure.ac scripts for a long time, and now,
unexpectedly, on a new Kubuntu 11.04 installation and on a Fedora 15
install, libtool not longer generates and installs shared objects. Same
scripts I've used before, different behavior
time, and now,
unexpectedly, on a new Kubuntu 11.04 installation and on a Fedora 15
install, libtool not longer generates and installs shared objects. Same
scripts I've used before, different behavior.
I don't know if this had ever worked, but the culprit seems to be this part
of your
Charles Wilson libtool at cwilson.fastmail.fm writes:
No, what it means is that, IF the project maintainers want to support
shared libraries (DLLs) on win32, then they must do the following -- and
this is true regardless of whether libtool is involved.
I think the real problem is that we
Vadim Zeitlin vz-libtool at zeitlins.org writes:
And as this project build options also include -std=c++0x,
__STRICT_ANSI__ is defined. For the compiler I use it would be enough to
add _CRTIMP in front of the declaration as this is how _putenv() is really
declared in /usr/i686-w64-mingw32/sys
and useful are subjective, of course, but what seems undeniably
objective to me is that currently libtool by default doesn't create shared
libraries under Windows at all, even with --disable-static (although,
again, --disable-static shouldn't be considered as a solution for this) and
you need to force
/
___
https://lists.gnu.org/mailman/listinfo/libtool
are never created at all.
PR
PR If you really are targeting Windows (or some other platform which needs
PR -no-undefined to build libtool libraries) then you really do get a failure
PR if there are undefined symbols.
Yes but *only* if you had -no-undefined in your Makefile.am. If you do
of whether libtool is involved.
1) Ensure that when building for win32, that the various object files
that will be combined into the DLL, as well as the library dependencies
(-lwhatever) are such that there WILL BE no undefined symbols, at least
*when building for win32*. Otherwise, ld will refuse
Charles Wilson libtool at cwilson.fastmail.fm writes:
A more interesting question is if the current situation with libtool can
be improved because I continue to believe that getting a static library
when you're trying to build a shared one can be very unexpected. And this
can be the case
Hello,
I'm using libtool 2.4 under Cygwin 1.7 to build a project using
i686-w64-mingw32-g++ 4.5.3 cross-compiler. This mostly works just fine (in
particular, it's a real relief to not have to worry about the identity
mounts and paths compatibility between MinGW and Cygwin) but I get an error
incantation) you're using for which the
detection fails?
Maybe we can figure out why func_win32_libid() is failing.
--
Chuck
Hi Chuck,
I guess func_win32_libid() is not failing but the gcc/linker is
smarter than libtool expect; or that autoconf is misleading libtool.
At configure stage
- for this question it's
important that I have libwsutil.so.0 installed in my system. Now if try
to do staged install for libwiretap like this:
$ cd wsutil/ make DESTDIR=/tmp/test install
$ cd ../wiretap make DESTDIR=/tmp/test install
libtool relinks libwiretap.so against _system_ libwsutil.so
On 6/20/2011 3:32 AM, Marco atzeri wrote:
Hi Chuck,
I guess func_win32_libid() is not failing but the gcc/linker is
smarter than libtool expect; or that autoconf is misleading libtool.
/lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.a
/lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.dll.a
/lib/gcc/i686
On 6/17/2011 10:19 AM, Vadim Zeitlin wrote:
On Thu, 16 Jun 2011 19:10:39 -0500 (CDT) Bob Friesenhahn
bfrie...@simple.dallas.tx.us wrote:
BF Most projects using libtool come from Unix/Linux where auto-import
BF is the default so it can be seen that most projects already depend on
BF
could live
with falling back to a static library. But consider that
auto-importing is
relatively new so there should be proportionally few projects using it,
hence IMHO the risk of breakage remains reasonably small.
Most projects using libtool come from Unix/Linux where auto-import is
the default
Den 2011-06-17 01:15 skrev Bob Friesenhahn:
On Thu, 16 Jun 2011, Vadim Zeitlin wrote:
BF
BF In what way was libtool specifically requested to build a DLL?
I'm not sure about the details (please keep in mind that we're speaking
about libxml2 here and not my own project) but configure
On 6/17/2011 4:14 PM, Charles Wilson wrote:
On 6/17/2011 3:46 AM, Marco atzeri wrote:
on cygwin
lt_cv_deplibs_check_method=pass_all
is my workaround at configure stage to bypass incorrect
libtool detection of system capabilities and to allow
shared libs building.
It's not about system
the
detection fails?
Maybe we can figure out why func_win32_libid() is failing.
--
Chuck
___
https://lists.gnu.org/mailman/listinfo/libtool
On Thu, 16 Jun 2011, Vadim Zeitlin wrote:
different functions (_foo vs _imp__foo). So IMO creating a static library
when libtool was requested to build a DLL is never the right thing to do
under Windows. And while I hesitate to call this behaviour a bug because it
is clearly intentional, I'd
On Thu, 16 Jun 2011 15:36:24 -0500 (CDT) Bob Friesenhahn
bfrie...@simple.dallas.tx.us wrote:
BF On Thu, 16 Jun 2011, Vadim Zeitlin wrote:
BF different functions (_foo vs imp_foo). So IMO creating a static library
BF when libtool was requested to build a DLL is never the right thing to do
BF
On Thu, 16 Jun 2011, Vadim Zeitlin wrote:
BF
BF In what way was libtool specifically requested to build a DLL?
I'm not sure about the details (please keep in mind that we're speaking
about libxml2 here and not my own project) but configure[*] is passed
--disable-static option and AFAIK
On Thu, 16 Jun 2011 18:15:01 -0500 (CDT) Bob Friesenhahn
bfrie...@simple.dallas.tx.us wrote:
BF On Thu, 16 Jun 2011, Vadim Zeitlin wrote:
BF BF
BF BF In what way was libtool specifically requested to build a DLL?
BF
BF I'm not sure about the details (please keep in mind that we're speaking
library. But consider that auto-importing is
relatively new so there should be proportionally few projects using it,
hence IMHO the risk of breakage remains reasonably small.
Most projects using libtool come from Unix/Linux where auto-import
is the default so it can be seen that most projects already
the output of
make clean make; make g72x_test
Thanks,
Ralf
___
https://lists.gnu.org/mailman/listinfo/libtool
not appear to have
*** because the file extensions .a of this argument makes me believe
*** that it is just a static archive that I should not use here.
Ok, finally figured out what's going on here. libtool is in fact doing the
correct thing, the static library should not be linked in with the shared
not appear to have
*** because the file extensions .a of this argument makes me believe
*** that it is just a static archive that I should not use here.
I've discovered that if I manually add the .a files back into the g++ command
that libtool runs, then it will be linked correctly. So the problem
On Wednesday, April 27, 2011 22:49:11 Adam Nielsen wrote:
I'm trying to cross-compile a library under Linux to produce a Win32 .dll.
It needs to link in with static Boost libraries (which were also cross
compiled on the same machine) but libtool seems to refuse to do this:
*** Warning
and after the object file where the undefined references
appear, but in every case I get the libtool warnings that it's not linking the
library and then of course the resulting undefined references.
Where should I be placing the libraries on the command line so that libtool
will not ignore them
So I have more information on this problem.
At the link time, the executables here are linked to
some static libtool-built libs. They are picking up
the dependency_libs variable in the associate .la file.
I can prevent this by removing the .la file after installation
of those dependency
would rather live without sliced bread!)
But something has recently gone wrong and it is not working for me, due
to some libtool confusion on my part, probably.
The daily snapshot of the package can be obtained here:
ftp://ftp.unidata.ucar.edu/pub/netcdf/snapshot/netcdf-4-daily.tar.gz
I am
) in the
configure.ac, so the math library has been found and added to LIBS. But
libtool strips it away!
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?
It's explicitly removed -
if test
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
Hi all,
I'm trying to cross-compile a library under Linux to produce a Win32 .dll. It
needs to link in with static Boost libraries (which were also cross compiled
on the same machine) but libtool seems to refuse to do this:
*** Warning: Trying to link with static lib archive
/usr/i486
We have a project using libtool on a Cray-XT4 using pathscale.
For compiling in parallel, we are supposed to use the compiler
wrapper, in this case ftn, that adds various libraries. A particular
complexity is that one has to switch libraries between front and
back end nodes, and this is done
the libtool script ?
Thanks
Nitin.
-Original Message-
From: libtool-bounces+nkapoor=sensis@gnu.org
[mailto:libtool-bounces+nkapoor=sensis@gnu.org] On Behalf Of John R.
Cary
Sent: Friday, April 22, 2011 9:17 AM
To: libtool@gnu.org
Subject: Libtool adding libraries differently than needed
Hi Nitin,
I take the link line output from libtool and throw it into a shell
script, then
I remove those entries and run the script.
Thx...John
On 4/22/2011 10:25 AM, Kapoor, Nitin wrote:
Hi John,
How are you removing the following paths from you link:
/opt/fftw/3.2.2.1/lib/libfftw3.so
I am having a similar issue where libtool is passing
(/usr/sfw/lib/libstdc++.so) to the linker.
libtool: link: g++ -g -O2 -D_REENTRANT -pthreads -o .libs/EnumVal
src/EnumVal/EnumVal.o ../src/.libs/libxerces-c.so
/usr/sfw/lib/libstdc++.so -L/usr/sfw/lib -lnsl -lsocket -licuuc
-licudata -pthreads
's/postdep_objects=.*$/postdep_objects=/g' -e
's/link_all_deplibs=.*$/link_all_deplibs=no/g' libtool
sed -i.bak -e 's? -L/opt/fftw/3.2.[0-9]/lib ? ?g' -e 's?
/opt/fftw/3.2.[0-9]/lib ? ?g' libtool
# The general one does not seem to work?
# sed -i.bak -e 's? -L/opt/fftw/3.2.[0-9].[0
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 1ea9302bd1eadf25b466fcd7e8697e4bef111493 (commit)
from
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via d5d35c47e16b18158bf4984cc4371366d373bb2f (commit)
from
* Svante Signell wrote on Fri, Apr 08, 2011 at 09:01:56AM CEST:
# shlibpath_overrides_runpath is set to 'unknown' in libtool.m4
# and not defined under $host_os =gnu
# This patch make the tests/*demo* run.
--- libtool-2.4/libltdt/m4/libtool.m4.orig2011-02-03 21:33:56.0
+0100
Hello Nick,
* Nick Bowler wrote on Fri, Apr 01, 2011 at 04:04:21PM CEST:
I'm working on a project which uses libltdl to load modules, and I've
set it up in a manner pretty similar to what's described in the libtool
manual (10.3 Linking with dlopened modules, http://xrl.us/bjk9e5
the libraries and binaries get
installed to our prefix directory /opt/kmt. This currently takes very
long (~20 minutes) as libtool relinks all libraries.
[...]
Wow. That's terrible.
How can I avoid this additional relinking step during make install?
Generally, --enable-fast-install should
Hi Peter,
Sry, no, does not work.
Error is:
Making all in src
/bin/sh ../libtool --tag=F77 --mode=link nagfor -g -o libcirce1.la -rpath
/Users/reuter/Physik/progs/whizard/nag_trunk/dist/lib/circe1 circe1.lo
libtool: link: nagfor -Wl,-dynamiclib -Wl,-undefined
-Wl,dynamic_lookup -o .libs
is running install-libLTLIBRARIES and
install-pkglibLTLIBRARIES in parallel. Each one of these these rules
installs the libraries serially in a loop. However, if libtool is
relinking the libraries, it really needs to wait until the
prerequisite libraries from _other_ rules are installed. I'd bet
, it's a bug in Automake/Libtool
Here's an automake bug report for this one:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
I don't know if there was a recorded report before.
Andy
___
http://lists.gnu.org/mailman/listinfo/libtool
install-libLTLIBRARIES and
install-pkglibLTLIBRARIES in parallel.
Yes, it's a bug in Automake/Libtool
Here's an automake bug report for this one:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
I don't know if there was a recorded report before.
Andy
Thanks a lot
. The pkglib one
depends on the lib one.
It seems that make is running install-libLTLIBRARIES and
install-pkglibLTLIBRARIES in parallel. Each one of these these rules
installs the libraries serially in a loop. However, if libtool is
relinking the libraries, it really needs to wait until
On 03/22/2011 12:03 PM, Andy Wingo wrote:
I don't know if there was a recorded report before.
Actually it's a such kind of well-known issue in Fedora,
Fedora packagers take automake/libtool-based make -jN install
being broken for granted and simply don't use it.
Ralf
install-libLTLIBRARIES and
install-pkglibLTLIBRARIES in parallel.
Yes, it's a bug in Automake/Libtool
Here's an automake bug report for this one:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
I don't know if there was a recorded report before.
Andy
Thanks a lot
signature.asc
El mar, 22-03-2011 a las 05:34 -0700, Dan Nicholson escribió:
Then, as the bug looks to be in automake/libtool, there is no much
gnucash can do to fix this as they don't provide generated Makefile
(only Makefile.am and .in), no?
What they can do is split the libgnc-backend-xml-utils.la
Hi,
I try to use libtool to limit the number of symbols exported by a
shared library. My previous call to create this library looked like
this and worked fine:
g++ -shared -o ../libmylib.so libmylib.o -pthread -ldl
Now I modified it so that my resulting libmylib.so only exports
symbols
Den 2011-03-21 07:36 skrev Satz Klauer:
Hi,
I try to use libtool to limit the number of symbols exported by a
shared library. My previous call to create this library looked like
this and worked fine:
g++ -shared -o ../libmylib.so libmylib.o -pthread -ldl
Now I modified it so that my
On 3/21/11, Peter Rosin p...@lysator.liu.se wrote:
Den 2011-03-21 07:36 skrev Satz Klauer:
Hi,
I try to use libtool to limit the number of symbols exported by a
shared library. My previous call to create this library looked like
this and worked fine:
g++ -shared -o ../libmylib.so
Den 2011-03-21 12:34 skrev Satz Klauer:
On 3/21/11, Peter Rosin wrote:
So,
libtool --mode=compile g++ -o libmylib.lo libmylib.cpp
libtool --mode=link g++ -o ../libmylib.la libmylib.lo -pthread -ldl
-export-symbols-regex mylib_ -rpath /usr/local/lib
might work better (untested
, if libtool is
relinking the libraries, it really needs to wait until the
prerequisite libraries from _other_ rules are installed. I'd bet if
you do this:
echo install-pkglibLTLIBRARIES: install-libLTLIBRARIES
src/backend/xml/Makefile
it will work again. This seems like a bug in automake's
of these these rules
installs the libraries serially in a loop. However, if libtool is
relinking the libraries, it really needs to wait until the
prerequisite libraries from _other_ rules are installed. I'd bet if
you do this:
echo install-pkglibLTLIBRARIES: install-libLTLIBRARIES
src
about Libtool issues.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
:
We have some downstream opened bugs with similar cases, would you mind
asking for help with them here in the future once their respective
upstream refuse to fix the issues?
Feel free to come to this mailing list for help about Libtool issues.
Cheers,
Ralf
one of these these rules
installs the libraries serially in a loop. However, if libtool is
relinking the libraries, it really needs to wait until the
prerequisite libraries from _other_ rules are installed. I'd bet if
you do this:
echo install-pkglibLTLIBRARIES: install-libLTLIBRARIES
src
Hi Jürgen,
Does the attached patch work for you? I think it -Wl, quotes everything
necessary. Note that I hardcode -Wl, rather than ${wl} because some of
the options are supposed to be gcc options rather than ld ones (though
ld recently accepts them too, so it's not a big deal either way).
Hi Peter,
I will test your patch, thanks. Just a quick answer:
nagfor -V results in:
NAG Fortran Compiler Release 5.2(747)
Product NPMI652NA for Apple Intel Mac OSX 64-bit
Copyright 1990-2010 The Numerical Algorithms Group Ltd., Oxford, U.K.
Cheers,
JR
On 5 Mar 2011, at 17:24, Peter
On 03/01/2011 05:24 AM, Jürgen Reuter wrote:
Dear libtool team (cc to Peter)
as discussed with Peter I send to you a diff (compared to the
2.4 official version of libtool) to support the NAG Fortran compiler
on Darwin 64bit machines.
Thanks for your work on this.
case $cc_basename
Dear libtool team (cc to Peter)
as discussed with Peter I send to you a diff (compared to the
2.4 official version of libtool) to support the NAG Fortran compiler
on Darwin 64bit machines.
The two changes are (also attached as diff patches):
-- in the file libtool.m4:
*
diff -u libtool.m4
On 1 Mar 2011, at 16:11, Peter O'Gorman wrote:
On 03/01/2011 05:24 AM, Jürgen Reuter wrote:
Dear libtool team (cc to Peter)
as discussed with Peter I send to you a diff (compared to the
2.4 official version of libtool) to support the NAG Fortran compiler
on Darwin 64bit machines
Hello,
* Jürgen Reuter wrote on Tue, Mar 01, 2011 at 12:24:39PM CET:
as discussed with Peter I send to you a diff (compared to the
2.4 official version of libtool) to support the NAG Fortran compiler
on Darwin 64bit machines.
--- libtool.m4 2010-10-01 20:57:54.0 +0200
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via c44468e0ec23e4b72f1e37e98be23ae71b6d0ed1 (commit)
from
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via d6f69ef647cb09d1baed104e769377f743a8aa8f (commit)
from
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 9196966580f6853a31187a7a3c7e7ff36ef08982 (commit)
from
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 86562ff7358179df2c44669c53525a86b3723312 (commit)
from
1001 - 1100 of 5838 matches
Mail list logo
