Link is not supported on OS/2.
* build-aux/ltmain.in (fund_mode_install): Create an import library.
(fund_mode_link): Likewise.
---
build-aux/ltmain.in | 23 ---
1 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index
* m4/libtool.m4 (_LT_COMPILER_PIC): Same as the title.
---
m4/libtool.m4 | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index da29e57..f54c882 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -4068,6 +4068,11 @@ m4_if([$1],
* build-aux/ltmain.in (func_mode_link): Set need_relink to no on OS/2.
---
build-aux/ltmain.in |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index cf72c66..48ae7fa 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@
to
compile the whole project I cd into the new sub-directory I have added
and run make, however, the process does not go smoothly and ends with
the following error:
/bin/bash ../libtool --tag=CC --mode=link g++ -I../include
-L/usr/lib64 -L/usr/X11R6/lib64 -L/opt/mni_library/lib
-L/opt/vxl
Hello,
I'm having some trouble cross building libraries from a Linux machine
(Debian/unstable) using mingw-w64, seem libtool is looking for a lib
command to generate a .lib library, but the command is missing and I
can't find it in any package (on stackoverflow I've seen for the same
problem
Hi!
On 2014-09-05 13:28, raz...@eml.cc wrote:
I'm having some trouble cross building libraries from a Linux machine
(Debian/unstable) using mingw-w64, seem libtool is looking for a lib
command to generate a .lib library, but the command is missing and I
can't find it in any package
Hi Peter, thank you
attacched the zzip config.log.
But the problem seem to be with any lib I try to cross build with
mingw and libtool, I wasn't sure the mail was sent to the mailing list
(usually I see immediatly the sent mail in mutt but not in this case)
so I've done a sort of cross posting
On Fri, Sep 05, 2014 at 05:05:52PM +0200, Peter Rosin wrote:
On 2014-09-05 16:52, raz...@eml.cc wrote:
Hi Peter, thank you
attacched the zzip config.log.
Bleh, sorry, but could you also provide the output from
./libtool --config
from your build directory?
Attacched
dpkg -L
On 2014-09-05 17:19, raz...@eml.cc wrote:
On Fri, Sep 05, 2014 at 05:05:52PM +0200, Peter Rosin wrote:
On 2014-09-05 16:52, raz...@eml.cc wrote:
Hi Peter, thank you
attacched the zzip config.log.
Bleh, sorry, but could you also provide the output from
./libtool --config
from your
libtool --config:
# Commands used to build an old-style archive.
old_archive_cmds=lib -OUT:\$oldlib\$oldobjs\$old_deplibs
Looking in the libtool.m4 file, the only way for lib -OUT...
to be chosen is
if test yes = $lt_use_gnu_ld_interface
doesn't match.
Your libtool
Friendly ping?
+cc the libtool maintainers according to http://www.gnu.org/software/libtool/
If this is indeed a bug, I'd be willing to invest some time in trying
to fix it, but I'd need some pointers on what would be the proper way
to fix it...
I really think libtool should be creating
Follow-up Comment #1, sr #108637 (project libtool):
Small correction, step #4 should read Build dbus.
If someone could confirm this is indeed a bug and whether there's a good
workaround for it that would be great.
Thinking about it, my impression is that bintest should actually be a wrapper
Hi Filipe,
Filipe Brandenburger wrote:
Hi,
I'm trying to link binaries to libraries that are not installed on the
system, but just unpacked to a staging directory.
[SNIP]
Is this a libtool bug?
Any suggestions of workarounds?
(I also filed a bug at
http://savannah.gnu.org/support
URL:
http://savannah.gnu.org/support/?108637
Summary: libtool adds -rpath to staging directory
Project: GNU Libtool
Submitted by: None
Submitted on: Tue 19 Aug 2014 11:30:33 PM UTC
Category: None
Priority
/${platform} added to it...
I tried working around it by passing --with-sysroot=${stagedir} to the
dbus configure, but unfortunately that didn't work...
Do you have a suggestion of something I could do to accomplish what
I'm trying to accomplish?
Is this a libtool bug?
Any suggestions of workarounds
Hello,
One of our clients has LibTool installed on a server running Windows Server
2003. We are planning to upgrade their server to Windows Server 2012. Is
LibTools compatible with Windows Server 2012?
Thank you,
Bryan Fulton
[cid:cio_logo1fed64]
Bryan Fulton
JR Systems Administrator
/libtool/manual/libtool.html#FAQ
Bummer, that's even the only FAQ :) I would suggest adding
common dropped options in there, such as -f, so that a
search would find it.
Thanks again.
___
https://lists.gnu.org/mailman/listinfo/libtool
Hi!
On 2014-04-28 17:45, Akim Demaille wrote:
I'm trying to use -fsanitize=address on OS X using MacPorts' Clang++ 3.5.
The project consists of C++ libraries, on top of which is built a Python
module (with a thin C++ layer which needs to be compiled). Libtool
(2.4.2 - the name of a fine
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 13aa364c0c66f9f6b41f98772d0735039ac974a1 (commit)
from
Update of sr #108558 (project libtool):
Status:None = Done
___
Follow-up Comment #10:
Patch pushed.
Cheers,
Peter
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 da30ce4dc9554c80f1931600af2b8bbab486476e (commit)
from
On 2014-05-06 15:30, Peter Rosin wrote:
Follow-up Comment #8, sr #108558 (project libtool):
I have attached a patch that does the safe-safe-safe version.
Does it work for you?
*snip*
http://savannah.gnu.org/support/?108558
To not force everyone to follow the link, here's the patch
Follow-up Comment #8, sr #108558 (project libtool):
I have attached a patch that does the safe-safe-safe version.
Does it work for you?
Cheers,
Peter
(file #31318)
___
Additional Item Attachment:
File name: 0001-libtool-fix-nm-test
Follow-up Comment #9, sr #108558 (project libtool):
I have attached a patch that does the safe-safe-safe version.
Does it work for you?
Yes, it seems that it does.
___
Reply to this item at:
http://savannah.gnu.org/support/?108558
On 2014-05-06 15:30, Peter Rosin wrote:
Follow-up Comment #8, sr #108558 (project libtool):
I have attached a patch that does the safe-safe-safe version.
Does it work for you?
*snip*
http://savannah.gnu.org/support/?108558
To not force everyone to follow the link, here's the patch
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 5911665520a53415bafd8bb6da9989b5fe25df80 (commit)
from
Follow-up Comment #1, sr #108558 (project libtool):
Thanks for the report.
Just a quick note, Cygwin is not affected. This happens on
MSYS/MinGW only. On Cygwin, the Windows (or should I say DOS?)
NUL device is never involved.
cygwin$ /bin/nm -B /dev/null
/bin/nm: Warning: '/dev/null
Follow-up Comment #2, sr #108558 (project libtool):
I was not aware of the extent to which Cygwin is mangling
commandlines of pure-W32 programs it runs (since i don't
really use Cygwin; i do know it does some kind of conversion;
apparently, only in one direction). Evidently, it does not
replace
Follow-up Comment #3, sr #108558 (project libtool):
Well, in MSYS2 you can simply do:
nm -B /dev/thisfilebetternotexistotherwiseyoullbeintrouble
and get satisfactory results (file name and 'No such file'
in the output).
Can't say anything about MSYS1, haven't used it for some time
Follow-up Comment #1, sr #108559 (project libtool):
Isn't this a more direct approach, not affected by new and even
more aggressive optimizations?
-volatile const char * MAGIC_EXE = $magic_exe;
+#if __GNUC__ 4 || (__GNUC__ == 4 __GNUC_MINOR__ 5)
+# define externally_visible volatile
+#else
Follow-up Comment #4, sr #108558 (project libtool):
Well, in MSYS2 you can simply do:
nm -B /dev/thisfilebetternotexistotherwiseyoullbeintrouble
and get satisfactory results (file name and 'No such file'
in the output).
Can't say anything about MSYS1, haven't used it for some time
Follow-up Comment #2, sr #108559 (project libtool):
Yeah, that worked
___
Reply to this item at:
http://savannah.gnu.org/support/?108559
___
Message sent via/by Savannah
http
Update of sr #108559 (project libtool):
Status:None = Done
___
Follow-up Comment #3:
I have now pushed this change, thanks for testing!
Cheers,
Peter
Follow-up Comment #5, sr #108558 (project libtool):
Hmm, on second thought, that depends on MSYS (and MSYS2) still
thinking that an argument starting with more than two slashes
is a UNC path (or a switch). That might change if someone
points out that ///foo and /foo should be equivalent
Follow-up Comment #6, sr #108558 (project libtool):
Crap.
How about just opening a file that is known to not to exist?
Alternatively, give nm a real file that is at least 1 byte long (binutils nm
checks for filesize being 1 and fails quietly; having 1 byte makes it say
filename (which
Follow-up Comment #7, sr #108558 (project libtool):
Ok, something like this seems safer:
mkdir conftest.dir
case `$tmp_nm -B conftest.dir/nofile` in
*conftest.dir/nofile*)
blablabla
esac
rm -rf conftest.dir
But I don't know how non-GNU nm behaves, so the safe-safe-safe
version only does
Update of sr #107959 (project libtool):
Status:None = Done
___
Follow-up Comment #1:
Fixed a while ago by commit a5a4944fbb2bbd20adb12b.
Cheers,
Peter
URL:
http://savannah.gnu.org/support/?108558
Summary: libtool nm test does not really work for W32
versions of nm
Project: GNU Libtool
Submitted by: lrn
Submitted on: Fri 02 May 2014 05:10:04 AM GMT
Category: None
URL:
http://savannah.gnu.org/support/?108559
Summary: libtool binary wrappers fall prey to aggressive
optimizations
Project: GNU Libtool
Submitted by: lrn
Submitted on: Fri 02 May 2014 05:16:44 AM GMT
Category: None
Hi friends,
I'm trying to use -fsanitize=address on OS X using MacPorts' Clang++ 3.5.
The project consists of C++ libraries, on top of which is built a Python
module (with a thin C++ layer which needs to be compiled). Libtool
(2.4.2 - the name of a fine belgian band of electronic music btw
Hi Richard,
Thanks for bringing these to my attention.
A very brief look at the names of your patches makes me curious to know more...
I've added taking a proper look at them to my TODO, but I don't want to hold up
the release for them.
If you have time, I'm keeping a mirror of the Libtool
On 20/03/14 06:07, Gary V. Vaughan wrote:
On Mar 20, 2014, at 5:37 AM, Arnout Vandecappelle
arnout.vandecappe...@essensium.com
mailto:arnout.vandecappe...@essensium.com wrote:
[Please keep me in CC, I'm not on the list]
Dear libtool maintainers,
Is there a possibility for a new
On Thu, 2014-03-20 at 18:07 +1300, Gary V. Vaughan wrote:
On Mar 20, 2014, at 5:37 AM, Arnout Vandecappelle
arnout.vandecappe...@essensium.com wrote:
[Please keep me in CC, I'm not on the list]
Dear libtool maintainers,
Is there a possibility for a new libtool release in the foreseeable
On Mar 20, 2014, at 5:37 AM, Arnout Vandecappelle
arnout.vandecappe...@essensium.com wrote:
[Please keep me in CC, I'm not on the list]
Dear libtool maintainers,
Is there a possibility for a new libtool release in the foreseeable future?
Hi Arnout,
Yes, absolutely. In fact
I have a question about how to work with libtool in a multi-toolchain
environment.
Background: We have a piece of software (MVAPICH2) we're trying to build
that uses libtool to create shared libraries for some C++ code. For ABI
compatibility reasons we need to compile this C++ code
On Fri, 14 Feb 2014, Eric Bavier wrote:
Obviously, this is just a single example, and it can be hacked around by
removing the -pthread option in the libtool script before linking, but I
wanted to ask any advice on how to work with libtool when libraries are
being built with two or more compiler
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 053df7eb31d21c6d6dbe54c44f42009efec9d0c9 (commit)
via
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 c18b2d494e03ed15407c65b1de4b2231d733fb75 (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 fa83d293d95e2e3bdfbfe739fc12e5c3a6307b64 (commit)
from
of GNU libtool are you using?
Peter
On Jan 31, 2014, at 3:06 PM, Michael C. Grant m...@cvxr.com wrote:
Gary,
Sorry for the delay. I think I'm going to have to give up on this one. I'm
afraid my understanding of libtool internals as well as Darwin -framework
idiosyncracies
Gary,
Sorry for the delay. I think I'm going to have to give up on this one. I'm
afraid my understanding of libtool internals as well as Darwin -framework
idiosyncracies are insufficient to the task.
Fortunately, the issue we were having with Octave compilation has been resolved
by other
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 70ff0e04c9dda19b74c88005abed3c1ca4adc3fc (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 525cddd2bcea4c565d6dd1d2d55dd1de1a476b67 (commit)
via
, I keep a mirror of libtool
athttp://github.com/gvvaughan/GNU-libtool, so that might be a more convenient
way for you to submit a pull request than dropping patch attachments into the
mailing list.
Ah, perfect. I'll submit a pull request there.
I have a couple of small fixes of my own that I
Hi Michael,
[moved to libtool-patches list]
On Jan 14, 2014, at 11:45 AM, Michael C. Grant m...@cvxr.com wrote:
I'm trying to compile GNU Octave and its new Qt GUI on a Mac OSX with
Homebrew. Homebrew installs the Qt frameworks in
/usr/local/Cellar/qt/4.8.5/lib, so after some fiddling
QtGui -framework QtNetwork
However, the libtool script does not handle the -F argument through properly,
so it is stripped out of the linking process.
I created the following patch for the generated libtool script, which causes
libtool to treat -F exactly like it treats -L. This seems to do
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 2f75576d051fad9a8c0b274c5be1289d57c0b636 (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 5e5cf7a7d67a1af4752bf442a42a5a77dccacd3e (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 754721442a645b599113f53bae5ed76d804de5bd (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 1f14273e954361bde44143458098acd9723e54a2 (commit)
from
On 2014-01-03 02:01, Gary V. Vaughan wrote:
Joking aside, you're quite right, I'll shuffle the order of bootstrap.in
to leave that warning at the top, and remove the write bit from the
generated file.
Thanks for fixing that! (too)
Cheers,
Peter
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 b40922af00e13b7ab30d3dff6c63a7c9f6aece5d (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 95e1f34f7b1238c2ad3db25c820ded22c93d049f (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 da59d47a448f0a623c7f56632dbe8c3f864a450a (commit)
via
On 2014-01-02 01:32, Gary V. Vaughan wrote:
Peter's a7462c5 fix was applied to the generated bootstrap script
instead of the funclib.sh source, and had have been overwritten
the next time bootstrap was regenerated.
Nice catch! As my feeble defense, I claim that there should have
was regenerated.
Nice catch! As my feeble defense, I claim that there should have been a
generated, do not edit comment in the files that are generated with
funclib.sh. :-)
┌─┤gary@kamala│~/Dropbox/Projects/libtool--devo--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 8886f3b473da66de42c2f7aa43db7e8789018cca (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 581d90bacaec6c20d5a5f776bdcdd9512f724192 (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 4494446e43ccd60c1e91a707584841705d28e338 (commit)
from
. For mingw, everything builds, but
libtool builds *.a files instead of *.dll files, with this warning:
*** Warning: linker path does not have real file for library
-lbali-phy.exe.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can
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 a7462c5563e124e06f4f61ce2a9cea26cf8be390 (commit)
from
: [PATCH] libtool: update cached $GCC value when updating $GXX
In the meat of the _LT_LANG_CXX_CONFIG macro, and in invoked
macros, $GCC is used to indicate if g++ is used. $GCC is used
instead of $GXX if an invoced macro is written in a tag
agnositic way, like _LT_SYS_DYNAMIC_LINKER is. Note that GCC
On 2013-11-11 10:37, Peter Rosin wrote:
Will push in a couple of days unless there are valid objections.
Forget it. I am a moron. It would be more valid to simply remove
the GXX=no assignment, but I can't classify that as a bug. Sorry
for wasting your bandwidth.
Cheers,
Peter
./configured my project, I managed to build the
object files, but the final linking (performed by libtool)
fails. It is invoked in the following way:
./libtool --tag=CXX --mode=link g++ -D_GNU_SOURCE=1 -Dmain=SDL_main
-Ic:/mingw/msys/1.0/include/SDL -Ic:/mingw/msys/1.0/include/guile/2.0
-I
.
Although I did use the autotools to create a package,
I know only superficially how it is supposed to work.
Having ./configured my project, I managed to build the
object files, but the final linking (performed by libtool)
fails. It is invoked in the following way:
./libtool
it.
regards,
M.
___
https://lists.gnu.org/mailman/listinfo/libtool
is peculiar.
I can later try to add some of the options from the libtool invocation
generated
by autoconf to my invocation of gcc to see which particular option causes the
failure and then let you know. I think that your description of the way SDL
does
things on mingw is sound (and I
in some way, but SDL
initialization is peculiar.
I can later try to add some of the options from the libtool invocation
generated
by autoconf to my invocation of gcc to see which particular option causes the
failure and then let you know. I think that your description of the way SDL
very well be flawed in some way, but SDL
initialization is peculiar.
I can later try to add some of the options from the libtool
invocation generated by autoconf to my invocation of gcc to see
which particular option causes the failure and then let you know.
I think that your
(performed by libtool)
fails. It is invoked in the following way:
./libtool --tag=CXX --mode=link g++ -D_GNU_SOURCE=1 -Dmain=SDL_main
-Ic:/mingw/msys/1.0/include/SDL -Ic:/mingw/msys/1.0/include/guile/2.0
-I/usr/local/include -Ic:/mingw/msys/1.0/include-Wall -Werror -mwindows
-Lc:/mingw/msys/1.0
managed to build the
object files, but the final linking (performed by libtool)
fails. It is invoked in the following way:
./libtool --tag=CXX --mode=link g++ -D_GNU_SOURCE=1 -Dmain=SDL_main
-Ic:/mingw/msys/1.0/include/SDL -Ic:/mingw/msys/1.0/include/guile/2.0
-I/usr/local/include -Ic
Hi,
I did apply that change, i.e. replaced AM_LDFLAGS with slayer_LDADD and
moved the definition to the end of the src/Makefile.am. The libtool is
right now invoked this way:
/bin/sh ../libtool --tag=CXX --mode=link g++ -D_GNU_SOURCE=1
-Dmain=SDL_main -Ic:/mingw/msys/1.0/include/SDL
-Ic:/mingw
On 2013-11-07 23:39, Panicz Maciej Godek wrote:
Hi,
I did apply that change, i.e. replaced AM_LDFLAGS with slayer_LDADD and moved
the definition to the end of the src/Makefile.am. The libtool is right now
invoked this way:
/bin/sh ../libtool --tag=CXX --mode=link g++ -D_GNU_SOURCE=1
Libtoolers!
The Libtool Team is pleased to announce the release of libtool 2.4.2.418.
This is a preliminary alpha release to begin platform testing in
preparation for the next stable release.
I built 2.4.2.418 on x86_64-pc-solaris2.11 (OpenIndiana 151a8) with
the Oracle Studio 12.3
Hi Tim,
On 6 Nov 2013, at 11:20, Tim Mooney tim.moo...@ndsu.edu wrote:
The Libtool Team is pleased to announce the release of libtool 2.4.2.418.
This is a preliminary alpha release to begin platform testing in
preparation for the next stable release.
I built 2.4.2.418 on x86_64-pc
Hi Gary and Tim,
On Wed, 6 Nov 2013, Gary V. Vaughan wrote:
| Hi Tim,
|
| On 6 Nov 2013, at 11:20, Tim Mooney tim.moo...@ndsu.edu wrote:
| The Libtool Team is pleased to announce the release of libtool 2.4.2.418.
|
| This is a preliminary alpha release to begin platform testing
...@gnu.org
| Subject: [GNU Libtool 2.4.2.418] testsuite: 9 10 11 15 16 18 21 122
123 124 125 129 failed
| ..
|
| Saw this in the build log.
| --
| GEN libtoolize
| UX:sed: ERROR: Command garbled: s|^m4trace: -1-
AC_CONFIG_AUX_DIR[([]*||
| GEN libltdl
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 eea1df80de2239ae2962786cbcb33fa3e3b4533a (commit)
via
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.418 has been created
at 8ce3ae0ad103366fbc2511b55f8a174f1975937a (tag)
tagging
Libtoolers!
The Libtool Team is pleased to announce the release of libtool 2.4.2.418.
This is a preliminary alpha release to begin platform testing in
preparation for the next stable release.
GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU
21, 2013 at 5:15 PM, Robert Boehne rboe...@gmail.com wrote:
Mesa
On Sep 21, 2013 1:21 AM, Giuseppe Aprea giuseppe.ap...@gmail.com
wrote:
Thanks for your answer but I am not sure I understand it. Are you talking
about libtool, automake or mesalib installation?
The file I attached is given
the hard way, mainly as a
learning exercise.
Thanks again,
Michael
___
https://lists.gnu.org/mailman/listinfo/libtool
... just let me
know and
chalk it up to SUE.
Thanks,
Michael
___
https://lists.gnu.org/mailman/listinfo/libtool
to
build both native and cross-builds, depending on configuration /
arguments, so
using DESTDIR for prefixing the install tree is important. Right now,
I'm
working on native builds on an Ubuntu 12.04 32-bit x86 machine;
libtool
version = 2.4.2.)
I can't help with the libtool issue
these
scripts to
build both native and cross-builds, depending on configuration /
arguments, so
using DESTDIR for prefixing the install tree is important. Right now, I'm
working on native builds on an Ubuntu 12.04 32-bit x86 machine; libtool
version = 2.4.2.)
When building/installing gmp, I use
Hi all,
I have a problem during mesalib installation which seems connected with
libtool. I guess the problem may be due to my environment since I have
automake and libtool installed in non-standard places.
libtool is under ${GLOBAL_PREFIX}/libtool/${LIBTOOL_VERSION}/
(version=2.4.2)
automake
wrote:
Hi all,
I have a problem during mesalib installation which seems connected with
libtool. I guess the problem may be due to my environment since I have
automake and libtool installed in non-standard places.
libtool is under ${GLOBAL_PREFIX}/libtool/${LIBTOOL_VERSION}/
(version=2.4.2
Hi,
Is it possible to link static libraries to shared ones using libtool? I
tried passing -Wl,whole-archive -lmylib -Wl,-no-whole-archive in LDFLAGS.
The compilation was fine, but when I checked the nm output of the shared
lib, none of the functions of mylib was present in the output. I also
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 0ebb734910bf56186dd0c0e84b1c8be507bad336 (commit)
from
pages at
http://lists.gnu.org/archive/html/libtool/2013-09/index.html
http://lists.gnu.org/archive/html/bug-libtool/2013-09/index.html
doesn't list any mails from me, but the ones from you from this thread
are there, so I don't know whether any of the mails I send arrive at
the list..)
That's
601 - 700 of 5834 matches
Mail list logo
