> On Jul 5, 2024, at 8:05 AM, Ileana Dumitrescu
> wrote:
>
> On 04/07/2024 20:55, Gary V. Vaughan wrote:
>>> On Jul 2, 2024, at 12:01 PM, Václav Haisman wrote:
>>>
>>> On 28. 06. 24 0:41, Ozkan Sezer wrote:
>>>> [Sorry, I seem to
> On Jul 2, 2024, at 12:01 PM, Václav Haisman wrote:
>
> On 28. 06. 24 0:41, Ozkan Sezer wrote:
>> [Sorry, I seem to have deleted the mailing list message from my inbox]
>> Regarding -no_fixup_chains patch i.e.
>>
>> http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commitdiff;h=3d1baeeef90
> On Jan 8, 2019, at 3:48 PM, Gary V. Vaughan wrote:
>
> Hi Christopher,
Sorry Christoph - autocorrect fail :-(
> My current employer does not sign FSF disclaimers, so I have not been able to
> work on libtool for the last 4 years. I’m Cc:ing the libtool list where yo
Hi Christopher,
My current employer does not sign FSF disclaimers, so I have not been able to
work on libtool for the last 4 years. I’m Cc:ing the libtool list where you
might find someone who can help.
However, the intent of the exceptions is to allow you to build your software
using libtool
> On Mar 23, 2015, at 2:42 PM, Bob Friesenhahn
> wrote:
>> On Mon, 23 Mar 2015, Christian Rössel wrote:
>>
>> Dear Gary,
>>
>> thanks for libtool-2.4.6!
>>
>> I discovered some files in
>> http://ftpmirror.gnu.org/libtool/libtool-2.4.6.tar.gz that IMO don't belong
>> there. The filenames sta
Hi Václav,
You're right! I'm not sure why that file hasn't been moved to the public
FTP server yet, but I've uploaded again anyway. Hopefully one of those
will take, and the xz file should appear at ftp.gnu.org in the next hour
or two.
Thanks for the report!
Cheers,
--
G
Libtoolers!
The Libtool Team is pleased to announce the release of libtool 2.4.6.
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)
behin
ined, it slows things down
> significantly.
>
> So is there a way we can change things so its not calling
> func_quote_for_eval all the time with all the looping that entails?
One possibility would be to add a post-processing script that rewrites
the hook functions used by func_o
you have timed. I'd be very
happy to find a way to patch gl/build-aux/option-parser or its clients to
regain some of that speed, but I'm extremely reluctant to revert to the
hokey mishmash of m4 and shell that 2.4.2 was using purely for the sake of
speed -- it might be that for extremely
Hi Peter,
On Feb 6, 2015, at 9:46 AM, Peter Rosin wrote:
> On 2015-02-06 10:30, Gary V. Vaughan wrote:
>>> On Feb 6, 2015, at 9:22 AM, Peter Rosin wrote:
>>>
>>>> On 2015-02-04 15:48, Bob Friesenhahn wrote:
>>>>> On Wed, 4 Feb 2015, Robert Yang
> versions *at the time the package was created* is what matters?
The information is useful in bug reports, and our instructions for reporting a
bug to the list explicitly ask for the output from `libtool --version` which by
including their other autotool versions makes reproducing the reporters
environment a lot easier :-)
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
Jim,
Click the link at the bottom of every message from the list and follow the
instructions for unsubscribe on the page it takes you to.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
> On 5 Feb 2015, at 12:32, James Smith wrote:
>
> Please could somebody let me know how to get
On Jan 20, 2015, at 6:34 PM, Peter Rosin wrote:
>
> On 2015-01-20 18:24, Gary V. Vaughan wrote:
>> -# Copyright (C) 2010-2015 Free Software Foundation, Inc.
>> +# Copyright (C) 2010-2014 Free Software Foundation, Inc.
>
> That's why I felt so young today!
Seems li
Hi Eric,
> On Jan 20, 2015, at 5:34 PM, Eric Blake wrote:
>
> On 01/20/2015 10:24 AM, Gary V. Vaughan wrote:
>
>>* gl/build-aux/bootstrap.in, gl/build-aux/extract-trace,
>>gl/build-aux/funclib.sh, gl/build-aux/options-parser: Sync with
>>upstre
Hi Pavel,
On Dec 13, 2014, at 5:58 PM, Pavel Raiskup wrote:
>
> On Friday 12 of December 2014 11:17:03 Gary V. Vaughan wrote:
>> I'll commit a follow on patch, to tweak it like this, later today.
>
> Thanks for the patch! It is almost perfect. During testing I noted th
Libtoolers!
The Libtool Team is pleased to announce the release of libtool 2.4.5.
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)
behin
Hi Pavel,
On Dec 12, 2014, at 10:02 AM, Pavel Raiskup wrote:
> On Thursday 11 of December 2014 23:29:56 Gary V. Vaughan wrote:
>> I think it would work better to leave lt_lib_dlsearch_path_spec in the
>> generated file as it was before (just the heuristic configure time values)
Hi Pavel,
> On Dec 10, 2014, at 6:41 PM, Pavel Raiskup wrote:
>
> On Tuesday 09 of December 2014 19:38:53 Gary V. Vaughan wrote:
>>> .. however, maybe you think that quite problematic the share with ltdl.m4
>>> (via sys_lib_dlsearch_path). That is ?clearly? confi
> On Dec 9, 2014, at 1:53 PM, Pavel Raiskup wrote:
>
> On Tuesday 09 of December 2014 11:53:22 Gary V. Vaughan wrote:
>>> That makes sense. Ideally, we could make the variable ./configure time
>>> sensitive and also sensitive to environment. Something like
[remembered to remove Orion from the Cc: list this time as requested]
Hi Pavel,
> On 9 Dec 2014, at 08:14, Pavel Raiskup wrote:
>
>> On Monday 08 of December 2014 15:55:22 Gary V. Vaughan wrote:
>> [..]
>> LT_SYS_LIBRARY_PATH
>> [..]
>
> That LT_SYS_LIBR
nk it hurts to leave
them, so that LT_SYS_LIBRARY_PATH is not always necessary. Is it the case that
adding /lib64:/usr/lib64 is a pessimisation in some case?
>> * Should be fully backward compatible.
>
> Still valid ^.
Ack.
Cheers,
--
Gary V. Vaughan (gary AT vaughan DOT pe)
___
https://lists.gnu.org/mailman/listinfo/libtool
Hi Pavel,
> On Dec 5, 2014, at 11:58 AM, Pavel Raiskup wrote:
>
> On Friday 05 of December 2014 10:56:28 Gary V. Vaughan wrote:
>>> This really needs to be sorted out.
>>> However this approach does not match the s390x at least.
>>
>> As in `case $host_c
Hi Pavel,
> On Dec 5, 2014, at 10:07 AM, Pavel Raiskup wrote:
>
> On Thursday 04 of December 2014 17:51:28 Gary V. Vaughan wrote:
>> Hi Orion,
>> [...]
>> Does this work for you?
>>
>> diff --git a/m4/libtool.m4 b/m4/libtool.m4
>> [...]
>> +
t (aside from not being certain /sbin/ldconfig is
+ # available) Fedora on 64bit does not report /usr/lib64, even though
+ # it is searched at run-time.
+ case $host_cpu in
+# match at least x86_64, ia64, powerpc64*
+*64*) sys_lib_dlsearch_path_spec="/lib64 /usr/lib64
$sys_lib_dlsearch_
October 2011 - and I found no reference to the change
> specified for AIX.
Ah, I see what you mean. Apparently my PDFTex was not working when I updated
the manual pages on the website, now fixed. Thanks!
> sincerely,
> Michael
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
Hi Lawrence,
> On 2 Dec 2014, at 08:05, Lawrence Velázquez wrote:
>
>> On Dec 1, 2014, at 5:39 AM, Gary V. Vaughan wrote:
>>
>> Yes, as you discovered, starting with Libtool-2.4.3 GNU M4 is required by
>> libtoolize, because we now dynamically run the configure
looking for magic
strings heuristically). I did mention that in the NEWS and the release notes
for 2.4.3, but I agree that it would be more sensible to simply fail at
configure time when a suitable M4 is not found.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
> On 1 Dec 2014, at 09:58, Mich
Libtoolers!
The Libtool Team is pleased to announce the release of libtool 2.4.4.
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)
behin
> I really think libtool should be creating a wrapper script and not a
> binary with an rpath pointing to the stage directory, am I wrong?
No, I agree with you.
And I'd be happy to help you massage a suitable patch into something I can
apply to the repository.
> Cheers,
> Filip
Hi Pavel,
> On Nov 22, 2014, at 7:28 AM, Pavel Raiskup wrote:
>
> On Friday 21 of November 2014 19:31:51 Gary V. Vaughan wrote:
>> Starting slowly, your first patch conflates two separate changes. The
>> first of those bringing back the correct use of LT_LIB_DLLOAD so tha
tes also show a workaround if you want to use (plural!)
AC_CONFIG_MACRO_DIRS now, without depending on an unreleased Autoconf
build to bootstrap.
Or, in the common case, you may only need a single macro directory anyway,
in which case (singular) AC_CONFIG_MACRO_DIR continues to work just fine
istian
>
> [1] https://www.gnu.org/software/libtool/manual/libtool.html
>
>> On 2014-10-27 22:44, Gary V. Vaughan wrote:
>> Libtoolers!
>>
>> The Libtool Team is pleased to announce the release of libtool 2.4.3.
>>
>> GNU Libtool hides the complexity
Hi Peter,
> On Nov 2, 2014, at 8:43 PM, Peter Rosin wrote:
>
> On 2014-11-02 11:42, Gary V. Vaughan wrote:
>>
>> Sorry I didn't word my original reply more carefully. The stack-protector
>> patch was a no-brainer, and as such is included in 2.4.3 already.
&g
Hi Peter,
> On Nov 2, 2014, at 8:43 PM, Peter Rosin wrote:
>
> On 2014-11-02 11:42, Gary V. Vaughan wrote:
>>
>> Sorry I didn't word my original reply more carefully. The stack-protector
>> patch was a no-brainer, and as such is included in 2.4.3 already.
&g
Hi Pavel,
Sorry the lists are being slow this weekend :(
> On Oct 30, 2014, at 1:06 PM, Pavel Raiskup wrote:
>
> Thanks for the release, Gary and all!
>
> On Monday 27 of October 2014 21:44:02 Gary V. Vaughan wrote:
>> - Fix a long-standing bug when using libtoolize
[[Added back Cc: libtool-list]]
> On Nov 1, 2014, at 11:11 AM, Richard PALO wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Le 27/10/14 23:02, Gary V. Vaughan a écrit :
> | Hi Richard,
> |
> |> I'd like to see two patches committed:
> |&
Hii Pavel,
They've been working fine for me so far... CCed just to be sure! :-)
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
> On 31 Oct 2014, at 07:57, Pavel Raiskup wrote:
>
> Hi Gary, has something happened with libtool's mailing lists? I was
> unable to send th
Hi Václav,
> On Oct 28, 2014, at 7:29 PM, Václav Zeman wrote:
>
> On 27.10.2014 22:44, Gary V. Vaughan wrote:
>> Libtoolers!
>>
>> The Libtool Team is pleased to announce the release of libtool 2.4.3.
>> [...]
>
> I have just installed the new v
ding the
reason why the patch is necessary, what it fixes, and the rationale
thereof (and a ChangeLog entry or similar) I couldn't evaluate the purpose
or potential side-effects of the first patch. If you could provide those,
I'll certainly make the time to evaluat
Hi All,
> On Oct 23, 2014, at 8:10 PM, Gary V. Vaughan wrote:
>
> I plan to roll a release based off the v2.4.2 tag, incorporating fixes for
> version mismatches against Mac OS Yosemite this weekend - in consideration of
> the fact that there are still known regressions in
Libtoolers!
The Libtool Team is pleased to announce the release of libtool 2.4.3.
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)
behin
n
to base the release from, please reply ASAP :-)
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
se. The process
is fiddly and takes several hours to complete though, so I'll leave it for a
few days to give people a chance to point me at any other critical patches that
should be rolled in too...
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)___
https://lists.gnu.org/mailman/listinfo/libtool
NIT is for initializing the ltdl directory
in your project, so if you want to share the installed libltdl
instead of building your own, then just treat it like any other
library dependency on your system and check for symbols you need
from libltdl.la and presence of an ltdl.h :)
Cheers,
--
Gary V.
loser to the top of the list...
Unfortunately, I don't even have the time to finish the next release at the
moment =(O|
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
of the Libtool repo in my github account
to make submitting pull-requests as easy as possible. If you can find the time
to polish the ones you want in the release and submit them via github within a
month or so, there's still time to make the release :-)
Cheers,
--
Gary V. Vaughan (gary A
7;t need to
> carry patches and we don't need to generate configure etc.
>
> Thank you,
> Regards,
> Arnout
> --
> Arnout Vandecappelle arnout dot vandecappelle at essensium dot com
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)___
https://lists.gnu.org/mailman/listinfo/libtool
Hi Eric,
On Jan 28, 2014, at 8:35 AM, Eric Blake wrote:
> On 01/27/2014 12:24 PM, Gary V. Vaughan wrote:
>>> On Jan 28, 2014, at 2:30 AM, Eric Blake wrote:
>>>
>>>> On 01/26/2014 11:08 AM, Bruce Korb wrote:
>>>> Hi,
>>>>
>>>&
ination was
tested not the link itself?
I'll do some more tests when I get back to my computer, and adjust again
If necessary.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
rev-parse would result in a relative path, which would have to be
parsed by bootstrap and used as the cwd... and that might lead people to
believe bootstrap supports VPATHs, which would not work at all except in a
checked out tree with a working $GIT.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org
Hi Sam,
Thanks for pitching in with some help here.
> On Dec 27, 2013, at 1:06 AM, Sam Varshavchik wrote:
>
> Gary V. Vaughan
>> If the process isn't working properly, the maintainers of courier main
>> server are much better placed to help you find the righ
r libltdl files you just
installed separately.
If the process isn't working properly, the maintainers of courier main server
are much better placed to help you find the right combination of build
commands, or else fix bugs in their libltdl integration.
HTH,
--
Gary V. Vaughan (gary AT gnu D
> On Dec 26, 2013, at 12:05 AM, José María Roldán Gil
> wrote:
>
> How can be built libltdlc.la library?? Thanks
Usually, just:
make libltdlc.la
Is that not working for you? Please post exactly what you expect, and exactly
what you got, and why that was different than you wanted. Details o
ary V. Vaughan (gary AT gnu DOT org)
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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
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
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
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
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
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
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
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
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
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 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
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 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
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
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
Follow-up Comment #28, sr #108201 (project libtool):
On Thu 20 Dec 2012 04:48:06 GMT in comment #27 Richard PALO wrote:
> When is the next release planned then?
Soon.
I had hoped to find time to do all the necessary testing before the end of the
year, but with wedding and honeymoon to plan, at
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
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
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
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
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
so long! :-o
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
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
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
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
ikely after the next release.
Thoughts?
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
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
;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
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
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
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
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
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
lost a few bits of code when I split bootstrap up into
3 more manageable files. Various fixes already pushed.
If you don't want to update yet, any of the following should
work regardless:
./bootstrap --copy --force --gnulib-srcdir /path/to/gnulib
GNULIB_SRCDIR=/path/to/gnulib ./bootstrap -
nised option: `--copy'
G'ah! Sorry about that. I'm pushing a fix now.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
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 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
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
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
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
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
[[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
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
[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
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
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
1 - 100 of 744 matches
Mail list logo
