Hey,
Now that libtool is released, i reply the questions below
This is the Warning: linker path does not have real file for library
-lole32. problem, right?
libole32.a and friends are all part of the Win32 API, and are installed
by a proper mingw64 native non-multilib toolchain in
In case of doubt it might be easier to not try to change the actual
dependency graph at all, but merely the rules, which should be enough
to fix the problem you are targeting.
Rather than try to build debians freebsd-buildutils on my mac, I decided
to take the route of leaving the dependency
Split out of the original 3/4 patch. Not tested separately, but
3/4 passed make distcheck originally, and so does this series as
a whole.
Okay to push?
* Makefile.am (rebuild): Set the shell variable `revision' rather
than `correctver' for clarity of purpose.
(bootstrap_edit,
The vast majority of this patch gets thrown away further in the
series. It's only really here to show separately how each of the
affected rules can be run perfectly well from the build tree... IIRC
I only wrote them this way originally as a short hand for retyping
all those long paths... but they
This is another silly patch that ends up being mostly edited away
by the next couple of patches in the series... but I think it's
useful to split it out so that you can see what I'm thinking at
each stage. It was also a good exercise because after splitting,
I realised that the original 3/4
This is the original 4/4 patch, unchanged from last time. It still
passes `make distcheck' from a clean checkout and build on my mac.
Assuming strongly that this patch depends upon the semantics of 3/4
applied, I will review this patch after 3/4 is fixed
I haven't actually tried it
Another patch factored from the original 3/4. This is the first
readability improvement to the rules that got lengthier in the
last patch... now that the groundwork is done.
I did run a build and minimal testing (as I described earlier in
this series) from a clean tree without problems at this
The few remaining cases where I would have liked to use $, instead
of writing it out long-hand relative to the build tree more than
once, I've stored it in a shell variable and referenced that.
There are another couple of instances that don't show in this patch
where there was only a single $
Factored out of the origin 3/4 patch.
Okay to push?
* Makefile.am (libltdl/config/ltmain.sh): Pipe the output of
`$(LT_M4SH)' directly into `$(bootstrap_edit)' to avoid use
of superfluous intermediate file.
Signed-off-by: Gary V. Vaughan g...@gnu.org
---
ChangeLog |5 +
Makefile.am |
typu ahead...
On 23 Sep 2010, at 22:21, Gary V. Vaughan wrote:
I'm torn between running our
own minimal substitution to fill the values in from libtool.m4, or
having the make rule for libtool just edit them out. Thoughts?
Of course, I mean the rule for ltmain.sh could edit them out
as it
Hello Gary,
* Gary V. Vaughan wrote on Thu, Sep 23, 2010 at 05:21:19PM CEST:
I've pared this down to the absolute minimum necessary to fix the
bug it is targetting. I did run this through `make distcheck' (and
it passed), but most of the others following only got a cursory
`git clean -x -d
Hi Gary,
this isn't a review, I'm just adding a couple of hints that come to
mind at first glance.
* Gary V. Vaughan wrote on Thu, Sep 23, 2010 at 05:21:24PM CEST:
Rules are getting shorter and more readable again now. I'm assuming
there are no portability problems with $@ and $^ in regular
Hi!
This is a repost of an old patch. Ralf said a long time ago that I should
drop the fixes for the old testsuite, but since I'm short of problems in
the new testsuite and the old one isn't going away, I'm revisiting this.
This was first posted here as part of a much bigger patch:
On Fri, 24 Sep 2010, Peter Rosin wrote:
Hi!
I don't know how to set up the defines so that EXTERN becomes
1. extern when you use a static library
2. extern when you build a static library
3. extern declspec(dllimport) when you use a shared library
4. extern declspec(dllexport) when you build
Hi!
With the patch posted with subject: [PATCH] tests: import variables for MSVC.
I found that libtool tries to put some bad symbols in the generated
symbol lookup table leading to errors such as this:
libtool: link: (cd .libs /home/peda/automake/lib/compile cl -MD -Zi -EHsc -c
helldl.exeS.c)
Hello Peter,
* Peter Rosin wrote on Fri, Sep 17, 2010 at 08:44:43AM CEST:
need_lib_prefix.at currently fails with MSVC. I think the test
is there to ensure that weird systems continue to work even
if the testsuite is running on a normal system. weird in
this case are systems with
Hi Peter,
* Peter Rosin wrote on Fri, Sep 24, 2010 at 12:39:13AM CEST:
With the patch posted with subject: [PATCH] tests: import variables for MSVC.
I found that libtool tries to put some bad symbols in the generated
symbol lookup table leading to errors such as this:
Ok to push?
Yes, with
Hi Peter,
* Peter Rosin wrote on Fri, Sep 24, 2010 at 12:25:14AM CEST:
Subject: [PATCH] tests: import variables for MSVC.
* tests/depdemo/sysdep.h (EXTERN): New define, saying how to
declare variables that might need to be imported.
* tests/depdemo/l1/l1.h, tests/depdemo/l2/l2.h,
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 installs
Hello:
The new released libtool 2.4 fixed my compilation problem while linking
a dll with code compiled with -flto.
Now I have new problem with 32-bit.
I think libtool 2.4 breaks multi-lib 32-bit.
For 64-bit it was ok.
Also I didn't notice this error while using older libtool came with the
On 22/09/2010 09:49, Marco Atzeri wrote:
Dear developers,
is this bogus warning avoidable in the next release ?
libtool: link: warning:
`/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfontconfig.la'
seems to be moved
libtool: link: warning:
Hi Peter,
* Peter Rosin wrote on Thu, Sep 23, 2010 at 08:54:43AM CEST:
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.
Hello t7,
* t66...@gmail.com wrote on Thu, Sep 23, 2010 at 03:01:31AM CEST:
I don't know if my problem suites this description.
No, it doesn't.
Currently installed libtool on this system is,
ltmain.sh (GNU libtool) 2.2.6b
I recently tested the LTO feature of GCC (targeting windows)
Hello t7,
please consider using the bug-libtool list for bug reports and a real
name for posting, that is considered friendly. Thanks.
* t66...@gmail.com wrote on Thu, Sep 23, 2010 at 11:11:34AM CEST:
The new released libtool 2.4 fixed my compilation problem while
linking a dll with code
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, would you
--- Gio 23/9/10, Dave Korn ha scritto:
On 22/09/2010 09:49, Marco Atzeri
wrote:
Dear developers,
is this bogus warning avoidable in the next release ?
libtool: link: warning:
`/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfontconfig.la'
seems to be moved
libtool: link:
Just FYI...
I don't think the following scenario applies to either of you, but I ran
into the warning in the case described below -- and the warning is valid
(e.g. we shouldn't try to fix MY case).
I was using a cross compiler with sysroot support (cygwin-mingw) to
build cygwin's setup.exe. I
Good morning Peter,
* Peter Rosin wrote on Thu, Sep 23, 2010 at 10:40:48PM CEST:
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!
Ok, done, and they appeared just
Hello Marco,
thanks for the bug report.
* Marco Atzeri wrote on Wed, Sep 22, 2010 at 10:49:56AM CEST:
is this bogus warning avoidable in the next release ?
libtool: link: warning:
`/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfontconfig.la' seems to be
moved
libtool: link: warning:
On 9/24/2010 12:45 AM, Marco Atzeri wrote:
I am not sure to follow your explanation.
on cygwin
$cd /usr/lib
I'm cross building, using $build_os=cygwin, but $host_os=mingw32, and a
cross compiler. I am *not* building natively.
In this situation, and with the new sysroot support in
--- Ven 24/9/10, Marco Atzeri ha scritto:
--- Ven 24/9/10, Charles Wilson
ha scritto:
Just FYI...
I don't think the following scenario applies to either
of
you, but I ran
into the warning in the case described below -- and
the
warning is valid
(e.g. we shouldn't try to fix
31 matches
Mail list logo
