to the development versions of libtool, so the next
release will not suffer from this problem.
> Please tell me whether I can simply ignore the update
> message or not.
The message is harmless provided you have the contents of a matching
libtool.m4 in your aclocal.m4 file already.
Cheer
On Fri, Oct 05, 2001 at 06:22:43PM -0700, Paul Eggert wrote:
> > From: "Gary V. Vaughan" <[EMAIL PROTECTED]>
> > Date: Fri, 5 Oct 2001 22:46:36 +0100
> >
> > libtool needs to store lots of script snippets in shell variables to
> > be passed to eval
version system we use.
Cheers,
Gary.
On Tue, Dec 04, 2001 at 06:39:39PM -0500, Oliver wrote:
> Hello, we were using libtool 1.4a on Irix 6.5, with automake 1.5 and
> autoconf 2.52. We create some shared C++ libraries that require
> automatic template instantiation. Mips CC doe
that your assignments are on file,
so it is just a matter of my merging the patch in my copious free time!
Cheers,
Gary.
--
())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org)
( '/ Research Scientist http://www.oranda.demon.co.uk ,_())
/ )= GNU Hacker
that
library, and replaced the headers with the ones that describe the API of that
version.
Libtool is trying to make this happen automatically on as many systems as it
can, as long as the people who develop and/or package libraries for your system
maintain the libtool version numbers accordin
r two at most.
5. Try to shepherd any patches that arise from that release into the tree,
with the aim of releasing a mostly fixed 2.2.10 before the end of May if
everything goes well, and before the end of June in any case.
Anything I need to be aware of before I jump in?
Cheers,
--
Gary
On 5 May 2010, at 00:55, Ralf Wildenhues wrote:
> Hi Gary,
Hallo Ralf,
Let me start by clarifying the intent of my original post in this
thread:
"I'd really like to get back to making several releases
every year, just like we did back in the days of Libtool-1.2
through -1.4 (an
ple more test runs to complete, after which I'll upload to
alpha.gnu.org to solicit feedback...
Barring technical hiccoughs, expect it to arrive within a couple of days.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
___
http://lists.gnu.org/mailman/listinfo/libtool
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) behind a consistent, portable interface.
The Libtool Team is pleased to announce release
Hi Adam,
On 22 May 2010, at 00:23, Adam Mercer wrote:
> On Thu, May 20, 2010 at 19:22, Gary V. Vaughan wrote:
>> The Libtool Team is pleased to announce release candidate 2.2.7b of GNU
>> Libtool. If there are no serious deficiencies reported in this release,
>> it will b
Hi Roumen,
On 22 May 2010, at 03:26, Roumen Petrov wrote:
> Gary V. Vaughan wrote:
>>
>> The Libtool Team is pleased to announce release candidate 2.2.7b of GNU
>> Libtool. If there are no serious deficiencies reported in this release,
>> it will be renumber
Hi Alon,
On 22 May 2010, at 13:02, Alon Bar-Lev wrote:
> On Fri, May 21, 2010 at 3:22 AM, Gary V. Vaughan wrote:
>>
>> GNU Libtool hides the complexity of using shared libraries behind a
>> consistent, portable interface. GNU Libtool ships with GNU libltdl,
>> wh
As an added bonus, if you know that you won't be running the binaries
in the build tree (say, to run the package testsuite), you can specify
--fast-install at configure time to always do the initial link against
install tree paths.
HTH,
--
Gary V. Vaughan (g.
Libtoolers!
The Libtool Team is pleased to announce the 2.2.8 release of GNU Libtool.
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) b
Hi Eric,
On 5 Jun 2010, at 03:55, Eric Blake wrote:
> On 06/04/2010 02:52 PM, Gary V. Vaughan wrote:
>> - Log -
>> commit 4a649e5c369e3aa28887bb3f50dc6256811c99e6
>> Author: Gary V. Vaughan
>> Date: Sa
trying to reload another copy first... this would be an
interesting test to have in the next release to see what feedback it
brings.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
___
http://lists.gnu.org/mailman/listinfo/libtool
a 2.2.x release branch for 2.2.12, and we can start
thinking about a Windows friendly 2.4.0 towards the end of the year.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
___
http://lists.gnu.org/mailman/listinfo/libtool
Hi Vincent,
On 8 Jun 2010, at 15:17, Vincent Torri wrote:
> On Tue, 8 Jun 2010, Gary V. Vaughan wrote:
>
>> [[Adding Libtool List]]
>>
>> On 8 Jun 2010, at 08:42, Charles Wilson wrote:
>>> Which is why I don't think even the Peter's long-ready MSVC
On 8 Jun 2010, at 15:22, Peter Rosin wrote:
> Hi Gary!
Hey Peter!
> Den 2010-06-08 09:34 skrev Gary V. Vaughan:
>> [[Adding Libtool List]]
>>
>> On 8 Jun 2010, at 08:42, Charles Wilson wrote:
>>> Which is why I don't think even the Peter's long-rea
Hi Chris,
Forgive my jumping in again here...
On 8 Jun 2010, at 17:47, Christopher Hulbert wrote:
> On Tue, Jun 8, 2010 at 4:22 AM, Peter Rosin wrote:
>> Den 2010-06-08 09:34 skrev Gary V. Vaughan:
>>> On 8 Jun 2010, at 08:42, Charles Wilson wrote:
>>>> Which
Hi Chris,
On 8 Jun 2010, at 20:06, Christopher Hulbert wrote:
> On Tue, Jun 8, 2010 at 7:40 AM, Gary V. Vaughan wrote:
>>
>> I think it important to merge pr-msvc-support into master one way or
>> another so that it doesn't get ignored for any longer than it has alread
On 8 Jun 2010, at 19:11, Charles Wilson wrote:
> On 6/8/2010 2:46 AM, Gary V. Vaughan wrote:
>> On 8 Jun 2010, at 08:56, Charles Wilson wrote:
>>> What happens if libltdl is
>>> used to load (say) libtiff which has an automatic dependency on libjpeg?
>>> The in
Hi Bob,
On 8 Jun 2010, at 23:04, Bob Friesenhahn wrote:
> On Tue, 8 Jun 2010, Gary V. Vaughan wrote:
>>
>> More interesting still: I think things might blow up if the .la files
>> have been removed on a platform that does automatic deplib loading for
>> runtim
Hi Bob,
On 8 Jun 2010, at 23:19, Bob Friesenhahn wrote:
> On Tue, 8 Jun 2010, Gary V. Vaughan wrote:
>>>
>>> Obviously this is already working fine. Windows LoadLibrary() is smart
>>> enough to know what it has already loaded. The unloading sequence is mu
on
email that you distribute via a public list. Please don't do that. If your
company's mail gateway appends that text, you should simply send your public
postings through a gmail SMTP server or similar.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
___
http://lists.gnu.org/mailman/listinfo/libtool
Hi Christian,
On 9 Jun 2010, at 01:43, Christian Rössel wrote:
> Am 6/4/2010 1:44 PM, schrieb Gary V. Vaughan:
>
>> * Changes in supported systems or compilers:
>>
>> - Improved support for 64bit Windows (mingw64).
>> - Improved support for cegcc (Windows CE/Po
is/pkg/vtk/install/lib/vtk-5.6 -lvtkCommon
>
> cd ../p3
> /bin/sh ../../libtool --tag=CXX --mode=link g++ -o libviewer.la -rpath
> /local/cchris/pkg/libtool/test22/myinstall/lib viewer.lo ../p1/libhello.la
> ../p2/libprog.la
>
> Regards
> Christian Caremoli
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
___
http://lists.gnu.org/mailman/listinfo/libtool
Hi Peter,
[[Adding libtool list]]
On 9 Jun 2010, at 20:21, Peter Rosin wrote:
> Den 2010-06-09 14:50 skrev Gary V. Vaughan:
>> [[...]] we can begin to evaluate whether to use pr-support-msvc-branch
>> in 2.2.12, or wait for 2.4.0.
>
> I don't really care how th
Hi Christian,
[[Libtool list added back in to Cc:]]
On 9 Jun 2010, at 21:17, christian caremoli wrote:
> 2010/6/9 Gary V. Vaughan
> > Most likely your libhdf.la has -L/usr/libs in its dependency_libs entry.
> > You can fix that by editing the libhdf.la file to pass the
Libtoolers!
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) behind
a consistent, portable interface.
Here are the compressed sources:
'`
Generally when a libtool variable name ends with '_spec', that means it
relies on being evaluated with an appropriate environment before use.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
___
http://lists.gnu.org/mailman/listinfo/libtool
Hi Sam,
On 10 Jun 2010, at 02:35, Sam Steingold wrote:
> On 6/9/10, Gary V. Vaughan wrote:
>> On 10 Jun 2010, at 01:51, Sam Steingold wrote:
>>> EXPORT_DYNAMIC_FLAG_SPEC='@EXPORT_DYNAMIC_FLAG_SPEC@'
>>>
>>> alas, instead of
>>&
Hi Christian,
[[Libtool list added back in to Cc:]]
Please don't top post on technical lists, but thanks for not sending the long
logs to the list :)
On 9 Jun 2010, at 23:10, christian caremoli wrote:
> 2010/6/9 Gary V. Vaughan
> Hi Christian,
>
> [[Libtool list ad
Hi Paolo,
On 10 Jun 2010, at 08:18, Paolo Bonzini wrote:
> On 06/09/2010 04:46 PM, Gary V. Vaughan wrote:
>> Why so much cruft in ltmain.m4sh just to drive a different archiver? It
>> seems to me that this would be better and easier to maintain, test and extend
>> as a who
Hi Paolo,
On 10 Jun 2010, at 11:07, Gary V. Vaughan wrote:
> On 10 Jun 2010, at 08:18, Paolo Bonzini wrote:
>> On 06/09/2010 04:46 PM, Gary V. Vaughan wrote:
>>> Why so much cruft in ltmain.m4sh just to drive a different archiver? It
>>> seems to me that this wo
k. I could be wrong, of course :)
>
> Patch attached (or course, a final patch will have to change the manual as
> well) - thoughts?
And add some test coverage. I like it. And it gives us something to tide us
over until I've finished libltdl2 in 2012 ;)
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
___
http://lists.gnu.org/mailman/listinfo/libtool
Hi Peter,
On 10 Jun 2010, at 14:35, Peter Rosin wrote:
> Den 2010-06-09 16:46 skrev Gary V. Vaughan:
>> As far as I can tell, you are eminently more qualified than me to know
>> whether your patches are likely to have issues. If we can't do a straight
>> merge from y
Hi Peter,
On 10 Jun 2010, at 20:55, Peter Rosin wrote:
> Den 2010-06-10 11:14 skrev Gary V. Vaughan:
>>>>>8c17887ee34e73a2aeb127b94f5b76f45dc34017
>>>>
>>>> Why so much cruft in ltmain.m4sh just to drive a different archiver? It
>>>&g
implementation.
Otherwise I end up staring at it, and spending whole weekends trying
to understand why it handed back another useless file-not-found error.
;)
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
___
http://lists.gnu.org/mailman/listinfo/libtool
e subject line. All of the non-GNU lists I am on
> include the list name in the subject line.
You can do that with procmail too, and without bothering the rest of us with
spurious redundant text on every email subject header in the libtool folder:
http://lipas.uwasa.fi/~ts/info/procti
.0 to help make early adopters aware that the flurry
of patches from the last few weeks, has introduced a much larger than
patch-only micro release number increment would indicate.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message
On 2 Sep 2010, at 03:09, Ralf Wildenhues wrote:
> Hello Gary,
Thanks for the quick response.
> * Gary V. Vaughan wrote on Wed, Sep 01, 2010 at 10:00:20PM CEST:
>> Unless there are any unmerged patches or unresolved issues to bring to
>> my attention, I'll make a new libtoo
On 2 Sep 2010, at 03:50, Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Wed, Sep 01, 2010 at 10:39:18PM CEST:
>> I don't have time either until Sunday at the earliest.
>
> I don't either. So please let's move this a week or two off.
> Peter and Charles h
le, or
specified by some parameter?) shells, and rerun the testsuite
with each.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool
thout an equivalent *.obj addition to every
.cvsignore file)
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool
Hi Peter,
On 13 Sep 2010, at 12:53, Peter Rosin wrote:
> Den 2010-09-13 05:46 skrev Gary V. Vaughan:
>> Do we still need to maintain .cvsignore files for a cvs
>> mirror of our git repo, or is it safe to remove them now?
>
> What on earth would .cvsignore be useful for in
Hi Eric,
On 13 Sep 2010, at 21:44, Eric Blake wrote:
> On 09/13/2010 01:26 AM, Gary V. Vaughan wrote:
>>> What on earth would .cvsignore be useful for in this day and age?
>>
>> I had thought we maintained a readonly cvs protocol mirror from our
>> savannah git
I'm planning to make the belated 2.4 release in about 24 hours.
If there is any reason you'd like me to hold off for a bit longer,
please speak up now!
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed me
Hallo Ralf,
On 19 Sep 2010, at 14:40, Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Sun, Sep 19, 2010 at 06:03:19AM CEST:
>> I'm planning to make the belated 2.4 release in about 24 hours.
>
> Great!
>
>> If there is any reason you'd like me to hold off
Hallo Ralf,
On 19 Sep 2010, at 18:14, Ralf Wildenhues wrote:
>> * Gary V. Vaughan wrote on Sun, Sep 19, 2010 at 06:03:19AM CEST:
>>> I'm planning to make the belated 2.4 release in about 24 hours.
>
>>> If there is any reason you'd like me to hold off for
Hi Bob,
On 19 Sep 2010, at 21:41, Bob Friesenhahn wrote:
> On Sun, 19 Sep 2010, Gary V. Vaughan wrote:
>
>> I'm planning to make the belated 2.4 release in about 24 hours.
>
> Yesterday I ran the libtool test suite on various machines here. The test
> suite performed
On Sep 20, 2010, at 3:18 AM, Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Sun, Sep 19, 2010 at 01:20:17PM CEST:
>> On 19 Sep 2010, at 18:14, Ralf Wildenhues wrote:
>>> Rainer just confirmed a regression in this thread:
>>> <http://lists.gnu.org/archive/htm
ing AM_INIT_AUTOMAKE([1.11a]) in libtool's
configure.ac? Pity Automake doesn't use gnulibs `git-version-gen' so
that I could specify the particular revision with the compile script
patch that we want at libtool bootstrap time.
Cheers,
--
Gary V.
Thanks for the heads up before releasing with 1.11a though.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool
7) installed to
bootstrap the checked out sources yourself.
Please report bugs to , along with the verbose
output of any failed test groups, and the output from `./libtool --config.'
The README file explains how to capture the verbose test output.
Enjoy!
--
Gary V. Vaughan (g...@gnu.o
a new path with no spaces in it,
and then pass *that* path in to libtool.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool
[Please don't top post on technical lists]
Hi Roman,
On 23 Nov 2010, at 19:13, Gavrilov, Roman wrote:
> -Original Message-
> From: Gary V. Vaughan [mailto:g...@vaughan.pe]
> Sent: Tuesday, November 23, 2010 1:18 PM
> To: Gavrilov, Roman
> Cc: libtool@gnu.org
&g
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)
b
[[Moving to libtool list][
Chaps,
On 21 Oct 2011, at 19:02, Gary V. Vaughan wrote:
> On 21 Oct 2011, at 16:11, Bruno Haible wrote:
>>> Set a neutral locale for rolling the release tarballs.
>>
>> I disagree with this advice. Yes, the first time you run a "make dis
ers that currently work (or at
least are supported and supposed to work) with the current release are
relying on LT_SCOPE magic from libltdl.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
Hi Peter,
On 25 Oct 2011, at 18:12, Peter Rosin wrote:
> Gary V. Vaughan skrev 2011-10-25 12:51:
>> I note that no other GNU projects that I'm aware of jump through all the
>> __declspec hoops that the libltdl API tries to provide through LT_SCOPE.
>> Is any of this s
Hi Peter, Bob, Chuck,
Thanks all for the feedback.
And Peter especially for running the torturous testsuites on Windows :)
On 25 Oct 2011, at 21:34, Peter Rosin wrote:
> Bob Friesenhahn skrev 2011-10-25 16:00:
>> On Tue, 25 Oct 2011, Gary V. Vaughan wrote:
>>> I note that no
I should also add:
On 25 Oct 2011, at 21:34, Peter Rosin wrote:
> Bob Friesenhahn skrev 2011-10-25 16:00:
>> On Tue, 25 Oct 2011, Gary V. Vaughan wrote:
>>> I note that no other GNU projects that I'm aware of jump through all the
>>> __declspec hoops that the libl
On 24 Oct 2011, at 20:36, Gary V. Vaughan wrote:
> On 21 Oct 2011, at 19:02, Gary V. Vaughan wrote:
>> On 21 Oct 2011, at 16:11, Bruno Haible wrote:
>>>> Set a neutral locale for rolling the release tarballs.
>>>
>>> I disagree with this advice. Yes, t
ttp://www.cygwin.com, but Libtool is
also compatible with mingw and MSYS if you prefer those.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
On 15 Nov 2011, at 03:20, Roumen Petrov wrote:
> Hello Gary,
Hi Roumen,
> After monster updates in repository please could you help me to bootstrap
> libtool.
> I don't like to create symbolic links, so I use --copy argument , but since
> 2011-11-08 it does not work.
On 16 Nov 2011, at 04:35, Roumen Petrov wrote:
> Hello Gary,
Hi Roumen,
> [SNIP]
>>> Usage: bootstrap MACRO_NAME FILE [...]
>>> Try `bootstrap --help' for more information.
>>> bootstrap: error: unrecognised option: `--copy'
>>>
the GNU
legal team. But,
don't worry, it is on the radar, and will come in due course.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
powerful and configurable bootstrap
script that was originally destined for gnulib itself, because the old libtool
bootstrap was brittle and bespoke, and the gnulib bootstrap needs to be heavily
patched (and those patches maintained) to manage our bootstrap process.
Cheers,
--
Gary V. Vaughan
fit binary, and possibly out of date
gnulib files are normal in this scenario.
If those other tools are not new enough to bootstrap Libtool, then you can take
a tarball made with 'make dist' from another machine and test with that inst
ed someone who is prepared to run semi-regular tests on
Windows, and preferably help to diagnose and write patches to fix any problems
uncovered.
While I sympathise with the horrors of working on Windows, it's not something I
want to take responsibility for myself. Particularly as I
otstrap --debug if there's not sufficient
detail in regular bootstrap output to see what has changed for the worse).
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
;file_magic ^x86 archive import|^x86 DLL'
>lt_cv_file_magic_cmd='func_win32_libid'
> else
># Keep this pattern in sync with the one in func_win32_libid.
>lt_cv_deplibs_check_method='file_magic file format
> (pei*-i386(.*architecture: i386)?|pe-arm-w
Hi Peter,
On Oct 7, 2012, at 4:37 PM, Peter Rosin wrote:
> On 2012-10-07 06:04, Gary V. Vaughan wrote:
>> On 7 Oct 2012, at 06:53, Peter Rosin wrote:
>>> objdump doesn't output "import" for me, at least not for any
>>> import lib I have given it. Chu
ikely after the next release.
Thoughts?
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
hear.
On 17 Oct 2012, at 20:57, Bob Friesenhahn wrote:
> On Wed, 17 Oct 2012, Gary V. Vaughan wrote:
>>
>> Libtool is just (a complicated) compiler wrapper, to make building and
>> linking against libraries easy to specify... be that on the command
>> line with a di
On Oct 18, 2012, at 7:08 PM, Peter Rosin wrote:
> Hi Gary!
Hi Peter,
> On 2012-10-17 11:41, Gary V. Vaughan wrote:
>> If the consensus is that Automake is not a good home for the libtool
>> compiler wrapper, then I still plan to split Libtool into two projects
>> as ou
Hello Mr. Strike,
On Oct 18, 2012, at 7:16 PM, NightStrike wrote:
> On Wed, Oct 17, 2012 at 11:27 AM, Gary V. Vaughan wrote:
>> Thanks to everyone for your feedback. Much appreciated.
>>
>> It seems that merging libtool into Automake would be an unpopular move all
>&g
so long! :-o
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
o pass, and
without requiring two full configure runs like we used to have -- then I'll be
very happy to test it. But please don't send any theories that might work if
only I'll spend several hours implementing and testing them... I've been down
this route before, and I'm already convinced that there isn't a good solution.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
r comes into play on any of the machines I use --
except to always set it to func_convert_file_noop :)
Let me know if the hints above get you any closer to a solution, or if you
are still stuck.
> I give. Too hard.
Windows makes me feel like that too ;)
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
at your
configure.ac is malformed and thus does not generate a full and proper
configure script with the necessary magic in it to get a working libtool.
You might be able to limp along using the install glib tool script from
Homebrew if your configure is not too brain-damaged
ms to have fallen off my radar. I don't recall having done
anything in that regard. Feel free to jog my memory.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
On Oct 26, 2012, at 12:10 PM, Yaroslav Bulatov wrote:
> Any ideas how to build libltdlc.la?
'make check' inside the libtool distribution builds libltdlc.la et al. for the
test suite.
Read the Makefile's (or the manual) for full instructions :-)
Cheers,
--
Gary V. Vaughan (g
est-suite everywhere).
HTH,
Gary
___
Reply to this item at:
<http://savannah.gnu.org/support/?108201>
___
Message sent via/by Savannah
http://savanna
ool rather than trying to install one from scratch
by yourself. Does your system come with apt or yum or similar?
HTH,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
from the build
>> directory?
No, libtool will take care of that (LD_LIBRARY_PATH is just one spelling
of that variable for linux and a few other Unices) automatically.
>> I notice that when I link against libtool created libraries in the
>> same Makefile I don't see this i
Hi Bob,
On 31 May 2013, at 09:57, "Gary V. Vaughan" wrote:
> On 31 May 2013, at 08:28, Bob Rossi wrote:
>> On Fri, May 24, 2013 at 07:15:50PM -0400, Bob Rossi wrote:
>>> I'm building a program that links against boost with libtool.
>>>
>>> Th
ith the somewhat
dull,
but very important process of applying patches that obviously move libtool
forward,
asking for revisions to patches that could be useful but are obviously lacking
in
some way, and flagging the rest for further review by me (in the remaining non-
obvious cases)? That would hel
Hi Peter,
On Aug 22, 2013, at 2:54 PM, Peter Rosin wrote:
> On 2013-08-22 09:40, Gary V. Vaughan wrote:
>>> Can we please get this simple patch pushed?
>>
>> Done.
>
> To me, it appears as if what you actually pushed was not what was posted?
I am an idiot. Tha
Hi Peter,
On Aug 22, 2013, at 8:58 PM, Peter Rosin wrote:
> On 2013-08-22 10:20, Gary V. Vaughan wrote:
>> On Aug 22, 2013, at 2:54 PM, Peter Rosin wrote:
>>> On 2013-08-22 09:40, Gary V. Vaughan wrote:
>>>>> Can we please get this simple patch pushed?
&g
Hi Alan,
Thanks for the fast feedback.
On Aug 22, 2013, at 10:48 PM, Alan Modra wrote:
> On Thu, Aug 22, 2013 at 09:34:10PM +0700, Gary V. Vaughan wrote:
>>> How can it be correct to say "-m elf32lppclinux" (32-bit) when $host is
>>> explicitly 64-bit? That seems
as making a list of
links to the list archives for patches that have not been evaluated would
help get Libtool out of the hole it is currently in with a severe lack of
developer-hours to keep it moving forward.
Please contact me via the list or privately if you would like to help.
Cheers,
--
Gary
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
e API in libtool.m4 for checking
whether compiler options work: _LT_COMPILER_OPTION.
While I wouldn’t recommend relying on internal APIs in your own code, it’s
definitely useful to study the implementation to see how you can do something
similar for your own code.
HTH,
--
Gary V. Vaughan (gary AT
x27;"\?'"$flag:test"'"\? ' stdout
> stdout:
> ./libtool.at:120: exit code was 1, expected 0
> 21. libtool.at:60: FAILED (libtool.at:120)
>
>
> Let me know what other useful information I can provide.
A fix? ;-)
> There&#x
n it before pushing it...
I don't have access to any Windows environments, but your patch works
correctly for me on various flavours of Mac OS, GNU/Linux, Solaris, HPUX,
and AIX -- I no longer have access to Tru64 Unix, SCO Unix or IRIX.
Thanks for the quick fix. Assuming it works on cygwin, m
On Nov 20, 2013, at 12:32 PM, Gary V. Vaughan wrote:
> Hi Ozkan, Petor,
^H^H^H^H^H^H^HPeter, *blush*
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
https://lists.gnu.org/mailman/listinfo/libtool
y without a
manual rebootstrap :-(
Patches welcome... I've added it to my TODO list to look at after the next
release too, in case no one else has time or inclination before then.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
Hi Peter,
On Dec 9, 2013, at 11:52 AM, Peter Rosin wrote:
> On 2013-12-07 08:53, Gary V. Vaughan wrote:
>> On 6 Dec 2013, at 21:11, Peter Rosin wrote:
>>> inline-source: error: file 'build-aux/funclib.sh' not found
>>> inline-source: error: file
301 - 400 of 772 matches
Mail list logo
