Den 2010-05-03 22:03 skrev Ralf Wildenhues:
* Jef Driesen wrote on Mon, May 03, 2010 at 08:24:09PM CEST:
Yes, I have read the libtool manual, but it doesn't contain much
info about the resulting filename. Most of the info is about the
c:r:a scheme for input, not the output.
Yes, because the ou
in #4, it also needs to be explicitly mentioned
in #6.
Ah, ok. Yes, you're right. Feel free to commit a patch to
s/removed/& or changed/ in 6.
I've pushed the attached patch...
Cheers,
Peter
2010-05-05 Peter Rosin
Clarify versioning algorithm documentation.
*
Den 2010-05-06 19:45 skrev Jason Curl:
On 04/05/2010 20:41, Peter Rosin wrote:
Den 2010-05-04 20:00 skrev Ralf Wildenhues:
Ah, ok. Yes, you're right. Feel free to commit a patch to
s/removed/& or changed/ in 6.
Sorry I came in late for the discussion. Is it correct to interpret
&qu
Hi Gary!
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-ready MSVC patches, nor
my pile of pending patches, are candidates for this extremely shortened
release cycle.
Regardin
Den 2010-06-08 10:22 skrev Peter Rosin:
It seems odd both to (a) have entries from 2009 in the (future-to-be) 2010
ChangeLog and (b) to make changes to the 2009 ChangeLog at this point.
I see that for the first merge of master into the branch last year I
updated the dates in the ChangeLog so
Den 2010-06-08 11:50 skrev Eric Blake:
On 06/08/2010 02:22 AM, Peter Rosin wrote:
There's already the pr-msvc-support branch, but when I tried to merge
master into it to make it easy to merge back later, the ChangeLog rotation
caused conflicts.
Do you have Bruno Haible's git-merge
Hi Christopher!
Den 2010-06-08 15:06 skrev Christopher Hulbert:
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 already.
I would like it to not get ig
Den 2010-06-08 15:40 skrev Christopher Hulbert:
On Tue, Jun 8, 2010 at 9:24 AM, Peter Rosin wrote:
I've had enough frustration here, methinks.
Sorry for my contribution to your frustration. I would just like to
see windows support in the mainstream to be done right, and the
attitude of
Den 2010-06-08 18:19 skrev Christopher Hulbert:
On Tue, Jun 8, 2010 at 11:03 AM, Peter Rosin wrote:
Den 2010-06-08 15:40 skrev Christopher Hulbert:
On Tue, Jun 8, 2010 at 9:24 AM, Peter Rosinwrote:
I've had enough frustration here, methinks.
Sorry for my contribution to
Hi Gary!
Den 2010-06-09 16:46 skrev Gary V. Vaughan:
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:
As far as I can tell, you are eminently more qualified than me to know
whether your patches are likely to have
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
seems to me that this would be better and easier to maintain, test and extend
as a whole new script. Let's call it, $prefix/libexec/
Hi!
Ok, let's take a step back. This is no longer really merging
work from the branch, so since A) using MS lib as archiver isn't
essential for MSVC support (at least I don't think so, I can't
remember any case where binutils ar hasn't worked for me, but
ar creates archives that are different so
Hi Ralf,
Den 2010-06-12 10:05 skrev Ralf Wildenhues:
* Peter Rosin wrote on Sat, Jun 12, 2010 at 12:49:18AM CEST:
The above may sound as if I'm opposed to moving the script to
automake, but I'm not. I'm mostly afraid of the script ending up
where the cccl script - or should
Hi Ralf!
Den 2010-06-14 22:40 skrev Ralf Wildenhues:
[ adding automake-patches; this is
http://thread.gmane.org/gmane.comp.gnu.libtool.general/10927/focus=10954 ]
* Peter Rosin wrote on Mon, Jun 14, 2010 at 09:35:45AM CEST:
Den 2010-06-12 10:05 skrev Ralf Wildenhues:
Well, I sort of
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 this day and age?
> (I have a patch in my queue that tries to sanitize and
> make equiv
Den 2010-09-19 16:41 skrev Bob Friesenhahn:
> 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 quite well (better than a week or two ago
Hi Gary,
Den 2010-09-19 06:03 skrev Gary V. Vaughan:
> I'm planning to make the belated 2.4 release in about 24 hours.
Just a friendly ping, but only just now I pushed a change to the
'compile' script in automake and would like the new version in
the release if it's not too much to ask for. Than
Hi Ralf,
Den 2010-09-20 19:41 skrev Ralf Wildenhues:
> I'd really appreciate if you guys could send build logs to the autobuild
> server as I've been doing lately, much more than just posting
> non-verbose results on the list here.
>
> You don't need to have autobuild installed. When Eric instal
Den 2010-09-23 20:05 skrev Ralf Wildenhues:
>> I have plans to soon mail output from the v2.4 tag with OPTIONS as
>> below on MSYS:
> *snip*
>
> That looks all fine to me. Thanks!
Hi Ralf,
Ok, done, and they appeared just fine on the site too. Since you said
you were going to collect them, woul
Hi!
I have been looking at the loops in tests/bindir.at and I see
this:
for bindir in \
$curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0/bin/ \
$curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0/bin \
$curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0/ \
$curdir/usr/lib/gcc/i686-pc-cygwin/4
Hi!
FYI, I just uploaded the latest MSVC results, one FAIL in the
old testsuite, the rest is PASS/SKIP/XFAIL.
Should be a good base for future regression analysis.
Cheers,
Peter
___
http://lists.gnu.org/mailman/listinfo/libtool
Hi Simon,
Den 2010-10-12 11:19 skrev Simon Josefsson:
> Ralf Wildenhues writes:
>
>> I kinda like Simon's patch you referenced (wow, that's old!), so how
>> about this patch which takes from both your suggestions?
>
> I like it. Thanks, this closes a long-standing libtool concern of mine.
>
>
Hi!
I have been tinkering with a text describing the hoops to jump when
prepping a library for Windows. At some point it should be texified and
added to the manual, but I'm not the best candidate for that job so this
is plain ASCII for now.
Can you spot any errors?
(I have not actually tested th
Den 2010-10-13 20:50 skrev Ralf Wildenhues:
> Hi Peter,
>
> * Peter Rosin wrote on Wed, Oct 13, 2010 at 08:19:27PM CEST:
>> Can you spot any errors?
>
> See below. I've only checked for things obvious to me; I hope somebody
> else verifies the w32 semantics and deta
.
Indeed.
> Peter Rosin writes:
>> #if defined _WIN32 && !defined __GNUC__
>> # ifdef BUILDING_LIBFOO
>> # ifdef DLL_EXPORT
>> # define LIBFOO_SCOPE extern __declspec (dllexport)
>> # endif
>> # elif defined _MSC_VER || defined DLL_EXPORT
>> #
Den 2010-10-13 20:50 skrev Ralf Wildenhues:
> Hi Peter,
>
> * Peter Rosin wrote on Wed, Oct 13, 2010 at 08:19:27PM CEST:
>> Can you spot any errors?
>
> See below. I've only checked for things obvious to me; I hope somebody
> else verifies the w32 semantics and
Den 2010-10-14 13:09 skrev Simon Josefsson:
> Peter Rosin writes:
>
>>> For comparison, in my projects I'm using a variant of this:
>>>
>>> # ifndef GSASL_API
>>> # if defined GSASL_BUILDING && defined HAVE_VISIBILITY && HAVE_VI
Den 2010-10-14 12:31 skrev Peter Rosin:
> Den 2010-10-13 20:50 skrev Ralf Wildenhues:
>> Hi Peter,
>>
>> * Peter Rosin wrote on Wed, Oct 13, 2010 at 08:19:27PM CEST:
>>> Can you spot any errors?
>>
>> See below. I've only checked for things obvious
Hi Ethan,
Den 2010-11-08 21:39 skrev Ethan A Mallove:
> On 10/21/10 00:13, Ralf Wildenhues wrote:
>> Hello Ethan,
>>
>> * Ethan Mallove wrote on Wed, Oct 20, 2010 at 10:32:11PM CEST:
It looks like that gives us the link line we want, yet we still get the
libimf.so dependency:
$
Den 2011-01-01 04:53 skrev Dan McMahill:
> I am trying to build a program under cygwin but using the mingw tool
> chain in a fake cross build way. In my configure environment, I have:
>
> export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32
>
> as suggested by the libtool manual. I'm
tool --mode={link,relink,install}' commands
>> for the libraries and programs involved. We may provide better help
>> then.
>
> attached.
Ok, I found a couple of minutes to look at this. Can you check if this
patch helps?
(It still needs a ChangeLog etc...)
Cheers,
Pet
Den 2011-01-05 05:30 skrev Dan McMahill:
> On 1/4/2011 11:44 AM, Peter Rosin wrote:
>> Den 2011-01-04 05:39 skrev Dan McMahill:
>>> On 1/2/2011 12:37 AM, Ralf Wildenhues wrote:
>>>> Hi Dan,
>>>>
>>>> * Dan McMahill wrote on Sat, Jan 01, 2011 a
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
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/
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 config
Den 2011-06-23 11:22 skrev Vadim Zeitlin:
> Charles Wilson cwilson.fastmail.fm> writes:
>
>> On 6/21/2011 8:29 AM, Vadim Zeitlin wrote:
>>> Charles Wilson writes:
No, I think --disable-static, if specified, should actually *disable
static*. That should be sufficient.
If it's
Den 2011-06-23 14:25 skrev Vadim Zeitlin:
> On Thu, 23 Jun 2011 13:12:42 +0200 Peter Rosin wrote:
>
> PR> Den 2011-06-23 11:22 skrev Vadim Zeitlin:
> PR> > I have no idea whether -no-undefined is supposed to work like this but
> in
> PR> > any case it seems
Den 2011-06-28 13:47 skrev Dave Cottlehuber:
> Hi libtoolers,
>
> I am building 2 Win32 DLLs to be loaded into the erlang runtime VM as NIFs,
> based on snappy (mixed C & C++) and ejson/yajl (in C), all part of porting
> latest CouchDB trunk to Windows - config is at [8].
>
> They use a similar M
Den 2011-06-28 16:00 skrev Peter Rosin:
> Den 2011-06-28 13:47 skrev Dave Cottlehuber:
>> Hi libtoolers,
>>
>> I am building 2 Win32 DLLs to be loaded into the erlang runtime VM as NIFs,
>> based on snappy (mixed C & C++) and ejson/yajl (in C), all part of por
;
>>>
>>> When libtool is hacked up [4], I can get a cleanish link [5] but this
>>> clearly
>>> isn't the Right Thing To Do.
>>>
>>> What do I need to change, to ensure libtool passes the linker the same
>>> options
>>>
Gary V. Vaughan skrev 2011-10-25 12:51:
> Hi Chuck,
>
> 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 stuff still required on any non-museum Windows compiler
> that would break if
Bob Friesenhahn skrev 2011-10-25 16:00:
> On Tue, 25 Oct 2011, Gary V. Vaughan wrote:
>
>> Hi Chuck,
>>
>> 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 stuff still required on
Gary V. Vaughan skrev 2011-10-25 14:17:
> 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
Gary V. Vaughan skrev 2011-10-25 18:07:
> 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 awar
Charles Wilson skrev 2011-10-25 17:34:
> On 10/25/2011 11:03 AM, Peter Rosin wrote:
>> Gary V. Vaughan skrev 2011-10-25 14:17:
>> I configures both the way I usually configure libtool for msvc, i.e.
>>
>> ../configure autobuild_mode=msvc
>> CC="/c/cygwin/hom
Peter Rosin skrev 2011-10-25 21:11:
*snip*
> However, and more importantly, I also found this in the build logs of both
> stock 2.4.2 and 2.4.2-no-lt-scope:
>
> cl -link -EXPORT:lt__alloc_die,DATA
> ...
>-link -EXPORT:lt_ltdl_LTX_preloaded_symbols,DATA
> ...
>
>
Sorry to reply to self.
Peter Rosin skrev 2011-10-31 12:54:
> Peter Rosin skrev 2011-10-25 21:11:
>
> *snip*
>
>> However, and more importantly, I also found this in the build logs of both
>> stock 2.4.2 and 2.4.2-no-lt-scope:
>>
>> cl -link -EXPORT:l
Russ Allbery skrev 2012-01-07 03:13:
> Bob Friesenhahn writes:
>> Libtool's mode of operation works with static builds and on systems
>> where all libraries have to be supplied at link time.
>
> Of which there are very few still in existence in terms of widespread use,
> since most systems now us
Hi!
I used to use Cygwin/git to manage my libtool repo, and bootstrap it
with Cygwin. I would then build the bootstrapped libtool tree from
MSYS when I needed to do changes there, or check for regressions from
the Cygwin side.
This appears to no longer be possible, if I run "make check" from
MSY
Eric Blake skrev 2012-03-16 22:58:
> On 03/16/2012 03:54 PM, Peter Rosin wrote:
>> Hi!
>>
>> I used to use Cygwin/git to manage my libtool repo, and bootstrap it
>> with Cygwin. I would then build the bootstrapped libtool tree from
>> MSYS when I needed
On 2012-07-20 17:49, Vincent Torri wrote:
> hey
>
> I'm using mingw-w64 gcc (4.8.0 experimental)
>
> I have to link a library (named Evil) against libuuid.a. That is, in
> Makefile.am :
>
> libevil_la_LIBADD = -luuid etc..
>
> I have the warning that I pasted in the topic:
>
> ** Warning:
On 2012-07-21 13:16, Vincent Torri wrote:
> another solution is to just kill the stupid .la file. There is
I don't think the .la file is stupid as it lists other important
dependencies.
> absolutely NO reason to add to the linker static libraries that are
> ONLY used in my Evil library and that a
On 2012-07-21 14:49, Vincent Torri wrote:
> On Sat, Jul 21, 2012 at 2:41 PM, Peter Rosin wrote:
>> On 2012-07-21 13:16, Vincent Torri wrote:
>>> another solution is to just kill the stupid .la file. There is
>>
>> I don't think the .la file is stupid as it li
On 2012-07-22 04:00, JonY wrote:
> On 7/22/2012 00:43, Peter Rosin wrote:
>> On 2012-07-21 14:49, Vincent Torri wrote:
>>> On Sat, Jul 21, 2012 at 2:41 PM, Peter Rosin wrote:
>>>> On 2012-07-21 13:16, Vincent Torri wrote:
>>>>> absolutely NO reason t
On 2012-09-17 16:02, Bob Friesenhahn wrote:
> On Mon, 17 Sep 2012, Gary V. Vaughan wrote:
>
>> Hi Bob,
>>
>> On 17 ก.ย. 2012, at 2:48, Bob Friesenhahn
>> wrote:
>
>>> Please make it so that it is possible to use a source tree which has a .hg
>>> directory
>>> even if there is no 'git' program
On 2012-09-18 03:33, Gary V. Vaughan wrote:
> Hi Bob, Peter,
>
> On 17 ก.ย. 2012, at 23:22, Bob Friesenhahn
> wrote:
>> On Mon, 17 Sep 2012, Peter Rosin wrote:
>>>>
>>>> The 'm4' on this MinGW install is not a blessed version and a simple
On 2012-09-18 16:44, Gary V. Vaughan wrote:
> Hi Bob,
>
> On 18 ก.ย. 2012, at 21:23, Bob Friesenhahn
> wrote:
>> It used to be possible to run the libtool test suite in a MSYS shell
>> using a CIFS mount of the same source tree that I use for my Unix type
>> systems. I used to do that on a peri
On 2012-09-18 21:21, Peter Rosin wrote:
> On 2012-09-18 16:44, Gary V. Vaughan wrote:
>> Hi Bob,
>>
>> On 18 ก.ย. 2012, at 21:23, Bob Friesenhahn
>> wrote:
>>> It used to be possible to run the libtool test suite in a MSYS shell
>>> using a CIFS mo
On 2012-09-18 23:50, Peter Rosin wrote:
> On 2012-09-18 21:21, Peter Rosin wrote:
>> On 2012-09-18 16:44, Gary V. Vaughan wrote:
>>> Hi Bob,
>>>
>>> On 18 ก.ย. 2012, at 21:23, Bob Friesenhahn
>>> wrote:
>>>> It used to be possible to run
Hi!
After getting rid of the legacy testsuite (nice!), I'm
seeing a new failure with MSYS/MSVC in what used to be
the demo group, now demo.at.
I think it's a real libtool bug this time, and not a
simple testsuite issue.
When I do the MSVC run, I also specify that I want to
use "dumpbin -symbols"
On 2012-10-07 06:04, Gary V. Vaughan wrote:
> Hi Peter,
>
> On 7 Oct 2012, at 06:53, Peter Rosin wrote:
>> How is the below function supposed to work
>> when $file_magic_cmd is '$OBJDUMP -f' and not 'func_win32_libid'?
>
> I have no idea :(
>
&
On 2012-10-07 14:48, Gary V. Vaughan wrote:
> 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"
Hi Gary!
[dropping Automake@, since that part seems to have been shot down]
On 2012-10-17 11:41, Gary V. Vaughan wrote:
> Autotoolers,
>
> For quite some time now I've been thinking about simplifying Libtool,
> but I'm interested in feedback and more particularly buy-in from
> Automake maintaine
Hi Dennis!
On 2012-11-06 04:08, Dennis Clarke wrote:
>
> Firstly, I am willingto look at a git clone but I would prefer to work with a
> version that is considered "stable" and "released" and not alpha or beta
> grade. However, having said that :
>
> $ uname -a
> SunOS node002 5.10 Generic_1
On 2012-11-06 12:45, Peter Rosin wrote:
> The lt_libltdl_LTX_preloaded_symbols symbol is supposed to be in an
> automatically
> generated file, which isn't generated because configure does not recognize the
> $NM output. Libtool wants BSD style output.
>
>
>
&
On 2012-11-16 21:02, Dennis Clarke wrote:
> So I guess we have progress here .. sort of.
Good!
> $ pwd
> /usr/local/build/libtool-2.4.2_Nov_06_0153_SunOS5.10_sparcv9
> $ cp -p ./test-suite.log
> libtool-2.4.2_Nov_06_0153_SunOS5.10_sparcv9_test-suite.log
>
> see attached testsuite log file.
I
Follow-up Comment #10, sr #108201 (project libtool):
Dropping -no-undefined from LDFLAGS in export.at kills the test
on Windows and it's unacceptable to assume that elfdump
exists. Passing -no-undefined to libtool is NOT a misnomer and
-no-undefined is in fact a perfectly valid libtool option, not
Follow-up Comment #14, sr #108201 (project libtool):
Regarding the -no-undefined issue, I believe it is correct to
set -no-undefined in LDFLAGS in export.at. This is the case
since libtool is used to link in that test, and nothing else.
Or is LDFLAGS special in some way on Solaris, so that it get
Follow-up Comment #16, sr #108201 (project libtool):
I had an old git checkout from some time back (with some totally
unrelated work in it) and I used that to run the export test.
I'm not wasting hours on a full testsuite runs for this.
I tested once configuring with CC=g++ and once with CC=gcc. B
Follow-up Comment #18, sr #108201 (project libtool):
I believe gcc 4.5.3 is the latest stable for Cygwin. I do not
trust myself to be able to build a new gcc and verify that it
actually works for Cygwin without investing far more time than I
think is warranted. I imagine that there is some good re
Follow-up Comment #22, sr #108201 (project libtool):
I had a look in the code and it is only for Solaris that
old_archive_cmds and archive_cmds are rigged to include
$LDFLAGS. This is clearly a buggy thing to do and it explains
why -no-undefined is passed down to gcc for you.
However, I have litt
Follow-up Comment #24, sr #108201 (project libtool):
Hi again!
I have no quarel with the original change to augment
archive_expsym_cmds with ${wl}-h $wl$soname. That looks
like a no-brainer as it just matches archive_cmds. That
can go in at any time, as far as I'm concerned.
The testsuite change
Follow-up Comment #26, sr #108201 (project libtool):
I have pushed the code changes to m4/Libtool.m4 (as two separate
commits), but left the testsuite alone. Thank you for your work
on this!
I also added you to THANKS, I hope that was ok?
A libtool release is not on my table though.
Cheers,
Pet
On 2013-01-01 19:03, Gary V. Vaughan wrote:
> maint: remove unsupported Tested-by: tag.
>
> * build-aux/git-log-fix: Tested-by: line should not appear in the
> ChangeLog.
>
> Signed-off-by: Gary V. Vaughan
Hi Gary,
I just noticed this, and while I'm perfectly fine with
On 2013-01-18 17:32, Peter Rosin wrote:
> On 2013-01-01 19:03, Gary V. Vaughan wrote:
>> maint: remove unsupported Tested-by: tag.
>>
>> * build-aux/git-log-fix: Tested-by: line should not appear in the
>> ChangeLog.
>>
>> Signe
On 2013-01-28 14:07, Jan Engelhardt wrote:
> ---
> doc/libtool.texi |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/libtool.texi b/doc/libtool.texi
> index f7787f6..c06ddaa 100644
> --- a/doc/libtool.texi
> +++ b/doc/libtool.texi
> @@ -1696,7 +1696,7 @@ not
> libd
On 2013-01-28 17:33, Jan Engelhardt wrote:
> On Monday 2013-01-28 17:18, Peter Rosin wrote:
>> On 2013-01-28 14:07, Jan Engelhardt wrote:
>>> @@ -1696,7 +1696,7 @@ not
>>> libdir='/tmp/usr/local/lib'
>>> @end example
>>>
>>>
On 2013-04-23 16:12, NightStrike wrote:
> On Tue, Apr 23, 2013 at 4:02 AM, NightStrike wrote:
>> Building bfd in a particular cross compiler scenario requires that
>> cygpath be set to "echo". bfd configury has the tools to do this, but
>> it's broken. Configure properly does this:
>>
>> # test
On 2013-04-24 18:29, NightStrike wrote:
> On Wed, Apr 24, 2013 at 12:17 PM, NightStrike wrote:
>> On Wed, Apr 24, 2013 at 11:55 AM, NightStrike wrote:
>>> On Wed, Apr 24, 2013 at 2:47 AM, Peter Rosin wrote:
>>>> On 2013-04-23 16:12, NightStrike wrote:
>>
On 2013-04-24 22:24, NightStrike wrote:
> On Wed, Apr 24, 2013 at 4:16 PM, NightStrike wrote:
>> On Wed, Apr 24, 2013 at 4:01 PM, Peter Rosin wrote:
>>> So, it appears that LT_PATH_LD does not like your ld? I'd look into
>>> that.
>>
>> Where is the a
On 2013-04-26 13:58, NightStrike wrote:
> On Wed, Apr 24, 2013 at 8:52 PM, Peter Rosin wrote:
>> On 2013-04-24 22:24, NightStrike wrote:
>>> On Wed, Apr 24, 2013 at 4:16 PM, NightStrike wrote:
>>>> On Wed, Apr 24, 2013 at 4:01 PM, Peter Rosin wrote:
>>>>
On 2013-04-26 18:51, NightStrike wrote:
> On Fri, Apr 26, 2013 at 4:06 AM, Peter Rosin wrote:
>> On 2013-04-26 13:58, NightStrike wrote:
>>> On Wed, Apr 24, 2013 at 8:52 PM, Peter Rosin wrote:
>>>> On 2013-04-24 22:24, NightStrike wrote:
>>>>>
On 2013-04-26 23:48, Peter Rosin wrote:
> On 2013-04-26 18:51, NightStrike wrote:
>> On Fri, Apr 26, 2013 at 4:06 AM, Peter Rosin wrote:
>>> You had LD=i686-w64-mingw32-gcc, which will not make libtool happy. You
>>> might try LD=i686-w64-mingw32-ld instead, but you sh
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?
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
On 2013-08-22 10:20, Gary V. Vaughan wrote:
> 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
On 2013-08-22 17:48, 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 like utter garbage to me. What am I
>>> missing this time?
>
> As far as I underst
On 2013-09-10 00:34, JonY wrote:
> On 9/10/2013 02:12, Ozkan Sezer wrote:
>>
>> *** Warning: linker path does not have real file for library -lole32.
>> *** I have the capability to make that library automatically link in when
>> *** you link to this library. But I can only do this if you have a
>
On 2013-09-10 09:08, Ozkan Sezer wrote:
> Tell me if you need anything else.
Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
you.
Can you provide the output from "libtool --config" and
config.log? I'm not set up to easily duplicate your
environment...
Cheers,
Peter
On 2013-09-10 09:47, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 09:08, Ozkan Sezer wrote:
>>> Tell me if you need anything else.
>>
>> Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
>> you.
>>
>&
On 2013-09-10 10:55, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 09:47, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin wrote:
>>>> On 2013-09-10 09:08, Ozkan Sezer wrote:
>>>>> Tell me if you need anything else.
>>&
On 2013-09-10 11:26, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 10:55, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin wrote:
>>>> On 2013-09-10 09:47, Ozkan Sezer wrote:
>>>>> On 9/10/13, Peter Rosin wrote:
>>>>&
On 2013-09-10 11:50, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 11:26, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin wrote:
>>>> On 2013-09-10 10:55, Ozkan Sezer wrote:
>>>>> On 9/10/13, Peter Rosin wrote:
>>>>&
On 2013-09-10 12:25, Ozkan Sezer wrote:
> On 9/10/13, Ozkan Sezer wrote:
>> On 9/10/13, Peter Rosin wrote:
>>> On 2013-09-10 11:26, Ozkan Sezer wrote:
>>>> On 9/10/13, Peter Rosin wrote:
>>>>> On 2013-09-10 10:55, Ozkan Sezer wrote:
>>>>
On 2013-09-10 12:52, Ozkan Sezer wrote:
> That effectively cripples libtool for cross-compilers. Can the behavior
> be refined instead? Can you contact Charles Wilson about this?
He should be reading this list, if he has time...
Anyway, does this work?
Cheers,
Peter
diff --git a/m4/libtool.m4
On 2013-09-10 15:00, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 12:52, Ozkan Sezer wrote:
>>> That effectively cripples libtool for cross-compilers. Can the behavior
>>> be refined instead? Can you contact Charles Wilson about this?
>>
On 2013-09-10 15:29, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 15:00, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin wrote:
>>>> On 2013-09-10 12:52, Ozkan Sezer wrote:
>>>>> That effectively cripples libtool for cross
On 2013-09-10 15:56, Ozkan Sezer wrote:
> OK then, I'll keep an eye on mails from this list.
>
> (On an irrelevant note, the archive 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 f
On 2013-09-10 16:10, Peter Rosin wrote:
> On 2013-09-10 15:56, Ozkan Sezer wrote:
>> OK then, I'll keep an eye on mails from this list.
>>
>> (On an irrelevant note, the archive pages at
>> http://lists.gnu.org/archive/html/libtool/2013-09/index.html
>>
On 2013-09-17 09:50, Ozkan Sezer wrote:
> Any chance that this patch, or a patch that fixes bug #15321 [1],
> gets applied any time?
Yes, I'll push it in a bit. It's been almost a week, and I suspect
that noone will take the time to review this, so I'm just going to
push it shortly without review.
On 2013-09-17 10:23, Peter Rosin wrote:
> On 2013-09-17 09:50, Ozkan Sezer wrote:
>> Any chance that this patch, or a patch that fixes bug #15321 [1],
>> gets applied any time?
>
> Yes, I'll push it in a bit.
Pushed.
Cheers,
Peter
___
1 - 100 of 180 matches
Mail list logo
