Follow-up Comment #6, patch #6448 (project libtool):
Peter, you have mentioned, that you wanted to test this path with cccl, but
doesn't worked for you. I don't know if this is still an issue but there
exists a new patch for cccl mentioned on this site:
Follow-up Comment #7, patch #6448 (project libtool):
Hi Matthias!
Ok, I have tried that cccl script, but it still fails miserably to even build
libtool. So naturally I have no testsuite results. The failure looks the same
(on a cursory look) on master and on the pr-msvc-support branch so I do
Hello Bjorn,
* Bjorn Everts wrote on Thu, May 07, 2009 at 04:57:41PM CEST:
Additional Item Attachment, patch #6448 (project libtool):
File name: msvc.patch Size:12 KB
Reply to this item at:
http://savannah.gnu.org/patch/?6448
It is probably easier if you just
Additional Item Attachment, patch #6448 (project libtool):
File name: msvc.patch Size:12 KB
___
Reply to this item at:
http://savannah.gnu.org/patch/?6448
___
Den 2008-08-26 13:53, skrev Peter Rosin:
Charles Wilson skrev:
I also think that -winnt is too broad; and I'd really hate to see
the
massive uglification of the libtool code -- and thousands of
configure.ac's out there -- that would ensue if -mingw* were
/officially/ overloaded to
Not sure if I should drag this further along...
Den 2008-08-29 08:00, skrev Duft Markus:
Den 2008-08-26 13:53, skrev Peter Rosin:
Charles Wilson skrev:
I also think that -winnt is too broad; and I'd really hate to see
the
massive uglification of the libtool code -- and thousands of
Not sure if I should drag this further along...
So this is the last one ... :)
[snip]
__FUNCTION__
Valid only within a function and returns the undecorated name of
the
enclosing function (as a string). __FUNCTION__ is not expanded if
you
use the /EP or /P compiler option.
Ok, on
Peter Rosin wrote:
Charles Wilson skrev:
I also think that -winnt is too broad; and I'd really hate to see the
massive uglification of the libtool code -- and thousands of
configure.ac's out there -- that would ensue if -mingw* were
/officially/ overloaded to also represent the msvc-toolchain
Den 2008-08-29 13:27, skrev Duft Markus:
what if you do ./configure --host=i586-pc-winnt-msvc and have a link
called i586-pc-winnt-msvc-cl to cl.exe? that would make configure select
that compiler automatically.
Nope, doesn't work (after adjusting to i686-pc-winnt, since config.sub
complains
Den 2008-08-18 11:50, skrev Peter Rosin:
Ralf Wildenhues skrev:
PS: yes, all the other new tag variables need documenting in the manual,
too, before the branch can be merged into master.
Like this?
[EMAIL PROTECTED] postlink_cmds
+Commands necessary for finishing linking programs.
Den 2008-08-26 13:53, skrev Peter Rosin:
Charles Wilson skrev:
I also think that -winnt is too broad; and I'd really hate to see the
massive uglification of the libtool code -- and thousands of
configure.ac's out there -- that would ensue if -mingw* were
/officially/ overloaded to also
Peter Rosin wrote:
[snip]
Again, I just /mentioned/ the patchlevel issue. I'm only advocating
that
the API level of the ms runtime be encoded in $host. (Anything finer
grained is just as completely FUBARed^W difficult to manage as MS's
side-by-side solution).
So then id' suggest the
Peter Rosin skrev:
I created a simple dll, exporting one function doing a printf (some random
libc function). When building this dll, MSVC8 generated a manifest, but I
instead embedded the manifest pointing to an older msvcr80.
I.e. Embedded this:
assemblyIdentity type='win32'
Charles Wilson skrev:
I also think that -winnt is too broad; and I'd really hate to see the
massive uglification of the libtool code -- and thousands of
configure.ac's out there -- that would ensue if -mingw* were
/officially/ overloaded to also represent the msvc-toolchain case.
Thanks a
I Forgot to answer some things...
snip
My patches use the same host/build as MinGW when using MSYS, on the
grounds that the output from the MinGW tools and MSVC are compatible
(so same $host) and that MSYS is MSYS (same $build). That's also
how cccl has it (at least I think so...)
Markus Duft skrev:
I Forgot to answer some things...
snip
My patches use the same host/build as MinGW when using MSYS, on the
grounds that the output from the MinGW tools and MSVC are compatible
(so same $host) and that MSYS is MSYS (same $build). That's also
how cccl has it (at
Markus Duft skrev:
Markus Duft skrev:
The winnt was just the best that came to our ming,
since
the
result is plain win32 binaries.
winnt is not the only kind of output from MSVC. So, why is winnt
better than win9x/winxp/win2k3 or whatever? And other tools also
target winnt. To
Markus Duft wrote:
IMHO mingw produces code that is very different from what MSVC produces -
not only performance wise (in some cases).
And remember, you can only link code generated by mingw and by msvc
together if you're using C. Not C++ or any other symbol-mangled ABI.
PLUS, if you're
Markus Duft wrote:
IMHO mingw produces code that is very different from what MSVC
produces -
not only performance wise (in some cases).
And remember, you can only link code generated by mingw and by msvc
together if you're using C. Not C++ or any other symbol-mangled ABI.
PLUS, if
Charles Wilson skrev:
I've been using *-*-msvcXX to designate microsoft compiler-based host
triples. So, for Visual C++ 2005, it's -msvc80.
This really saved our bacon at work when we switched from VizStudio 2003
to 2005; the different host triple allowed us to keep old/new stuff
separate
Duft Markus skrev:
Markus Duft wrote:
IMHO mingw produces code that is very different from what MSVC
produces -
not only performance wise (in some cases).
And remember, you can only link code generated by mingw and by msvc
together if you're using C. Not C++ or any other symbol-mangled ABI.
Peter Rosin wrote:
That may not work, if Charles statements about dlls requiring different
patchlevels of msvcr80 holds. But that appears to not be the case:
I created a simple dll, exporting one function doing a printf (some random
libc function). When building this dll, MSVC8 generated a
Charles Wilson skrev:
Peter Rosin wrote:
That may not work, if Charles statements about dlls requiring different
patchlevels of msvcr80 holds. But that appears to not be the case:
I created a simple dll, exporting one function doing a printf (some random
libc function). When building this dll,
Peter Rosin wrote:
Do you remember if anything C++ was built with the offending patchlevel?
Or was it the open-source C libraries and nothing else that was built
differently?
Looks like there was also xerces-c, which is open-source but C++. So,
the root of the problem might not, in fact,
Hi Ralf,
Ralf Wildenhues skrev:
Hi Peter,
snip
So, I guess I'm saying that I'd prefer sticking to:
if test $GCC != yes; then
reload_cmds=false
fi
Ok to push?
Could this break parity support? I know It's not in the tree yet, but I
still hope, that ralf comes to
Peter Rosin skrev:
Hi Markus,
Markus Duft skrev:
Hi Ralf,
Ralf Wildenhues skrev:
Hi Peter,
snip
So, I guess I'm saying that I'd prefer sticking to:
if test $GCC != yes; then
reload_cmds=false
fi
Ok to push?
Could this break parity support? I know It's not in the tree
Peter Rosin skrev:
Hi Markus,
snip
Hold on! Since parity is using a $host matching *winnt*, this patch
doesn't
affect parity at all.
Yeah, right, i oversaw that :)
BTW, did you file a copyright assignment?
Sure, now 2 years ago, or so...
Cheers, Markus
I'm thinking of two
Hello Markus,
* Markus Duft wrote on Wed, Aug 20, 2008 at 09:26:10AM CEST:
Could this break parity support?
We try to ensure that it doesn't happen.
I know It's not in the tree yet, but I
still hope, that ralf comes to looking into my patch some day
Yes. My plan is to get Peter's
Hi Ralf,
Ralf Wildenhues skrev:
Hi Peter,
* Peter Rosin wrote on Sun, Aug 17, 2008 at 08:47:12AM CEST:
One easy way to avoid cc_basename is to simply leave this for the next
non-gnu tool to fix, i.e.:
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -3024,7 +3024,12 @@ case
Ralf Wildenhues skrev:
PS: yes, all the other new tag variables need documenting in the manual,
too, before the branch can be merged into master.
Like this?
One more hurdle is the $AR_SEP issue. It is normally set to ' ', but that
doesn't fit too well with make (as you have previously
Regarding the issue of merging the MSVC branch...
Peter Rosin skrev:
One more hurdle is the $AR_SEP issue. It is normally set to ' ', but that
doesn't fit too well with make (as you have previously mentioned, I'm
just raising the flag...).
I can see one way out, and that is to create a new
Ralf Wildenhues skrev:
* Peter Rosin wrote on Fri, Aug 15, 2008 at 11:36:14AM CEST:
Ralf Wildenhues skrev:
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4821,6 +4821,7 @@ _LT_EOF
mt -manifest @[EMAIL PROTECTED] -outputresource:@[EMAIL
PROTECTED];
$RM
* Peter Rosin wrote on Fri, Aug 15, 2008 at 01:44:30PM CEST:
Ralf Wildenhues skrev:
* Peter Rosin wrote on Wed, Aug 13, 2008 at 09:40:17PM CEST:
LIBA_SCOPE int (*const v12) (void);
Why doesn't this one need LIBA_SCOPE_VAR annotation only?
(I guess I'm to search for the answer to this one
* Peter Rosin wrote on Fri, Aug 15, 2008 at 11:36:14AM CEST:
Ralf Wildenhues skrev:
Please add Set to @code{false} on systems that cannot create
reloadable objects to the reload_cmds documentation in libtool.texi.
I used @samp(false) instead, as that seemed to be the usage for
constants in
Ralf Wildenhues skrev:
Hi Peter,
* Peter Rosin wrote on Wed, Aug 13, 2008 at 12:41:04PM CEST:
2008-08-13 Peter Rosin [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS)
[cygwin, mingw, pw32, cegcc] cl*: Indicate that reloadable
objects does not work.
Ralf Wildenhues skrev:
Hi Peter,
* Peter Rosin wrote on Wed, Aug 13, 2008 at 09:40:17PM CEST:
72: stresstest.at:31 Link option thorough search test
Automatic path conversion in MSYS doesn't kick in for the argument
-OUT:/some/absolute/path so lib.exe barfs.
Commenting out absolute paths
* Peter Rosin wrote on Wed, Aug 13, 2008 at 10:12:23PM CEST:
24: link-order.at:26 Link order test.
Exporting int c variable.
With MSVC, you can declare any variable with __decspec(dllimport), even
if you are not actually importing it. The only thing that happens is
that you get an extra
Hi Peter,
* Peter Rosin wrote on Wed, Aug 13, 2008 at 09:40:17PM CEST:
72: stresstest.at:31 Link option thorough search test
Automatic path conversion in MSYS doesn't kick in for the argument
-OUT:/some/absolute/path so lib.exe barfs.
Commenting out absolute paths from the stress test
Ralf Wildenhues skrev:
* Peter Rosin wrote on Wed, Aug 06, 2008 at 09:47:28AM CEST:
Ralf Wildenhues skrev:
* Peter Rosin wrote on Tue, Aug 05, 2008 at 10:38:14AM CEST:
Peter Rosin skrev:
16: duplicate_conv.at:25 duplicate convenience archive names
MS link doesn't have reloadable objects
Ralf Wildenhues skrev:
- (eval $AR -NOLOGO -OUT:conftest.lib conftest.$ac_objext conftest.err)
+ (eval $AR -NOLOGO -OUT:conftest.lib conftest.$ac_objext conftest.err 21)
Hi Ralf,
Is there a reason for this, I thought the log was there to help
diagnose what went wrong, and that more
* Peter Rosin wrote on Wed, Aug 13, 2008 at 11:00:33AM CEST:
Ralf Wildenhues skrev:
- (eval $AR -NOLOGO -OUT:conftest.lib conftest.$ac_objext conftest.err)
+ (eval $AR -NOLOGO -OUT:conftest.lib conftest.$ac_objext conftest.err
21)
Is there a reason for this,
Yes,
file 21
is completely
Ralf Wildenhues skrev:
* Peter Rosin wrote on Wed, Aug 13, 2008 at 11:00:33AM CEST:
Ralf Wildenhues skrev:
- (eval $AR -NOLOGO -OUT:conftest.lib conftest.$ac_objext conftest.err)
+ (eval $AR -NOLOGO -OUT:conftest.lib conftest.$ac_objext conftest.err 21)
Is there a reason for this,
Yes,
Peter Rosin skrev:
Ralf Wildenhues skrev:
* Peter Rosin wrote on Wed, Aug 06, 2008 at 09:47:28AM CEST:
Ralf Wildenhues skrev:
* Peter Rosin wrote on Tue, Aug 05, 2008 at 10:38:14AM CEST:
Peter Rosin skrev:
16: duplicate_conv.at:25 duplicate convenience archive names
MS link doesn't have
Peter Rosin skrev:
Peter Rosin skrev:
Attached, I'll work through all the failures to try to find out why
they fail...
*snip*
72: stresstest.at:31 Link option thorough search test
Automatic path conversion in MSYS doesn't kick in for the argument
-OUT:/some/absolute/path so lib.exe
Peter Rosin skrev:
Peter Rosin skrev:
Attached, I'll work through all the failures to try to find out why
they fail...
*snip*
24: link-order.at:26 Link order test.
Exporting int c variable.
With MSVC, you can declare any variable with __decspec(dllimport), even
if you are not actually
Peter Rosin skrev:
Peter Rosin skrev:
Ralf Wildenhues skrev:
*snip*
Please try the patch below for simplistic at-file support with $NM.
While testing, I set nm_file_list_spec to '@' and always_export_symbols
to yes on GNU/Linux, and saw no test failure, probably because my nm
also
* Peter Rosin wrote on Tue, Aug 12, 2008 at 10:38:45AM CEST:
Peter Rosin skrev:
It works to have it in LT_PATH_NM, so that's where I'd put it. Like
the attached patch...
That's a good idea.
Also, I tested the patch on the new testsuite and with this patch
I get the desired behaviour in the
* Ralf Wildenhues wrote on Wed, Aug 13, 2008 at 07:21:07AM CEST:
Sorry for the delay. I pushed that patch to the msvc branch.
2008-08-13 Ralf Wildenhues [EMAIL PROTECTED]
Peter Rosin [EMAIL PROTECTED]
Support for response files with $NM.
* libltdl/m4/libtool.m4
* Peter Rosin wrote on Wed, Aug 06, 2008 at 09:47:28AM CEST:
Ralf Wildenhues skrev:
* Peter Rosin wrote on Tue, Aug 05, 2008 at 10:38:14AM CEST:
Peter Rosin skrev:
16: duplicate_conv.at:25 duplicate convenience archive names
MS link doesn't have reloadable objects (i.e. like ld -r).
* Peter Rosin wrote on Sat, Aug 09, 2008 at 10:43:26AM CEST:
Ralf Wildenhues skrev:
* Peter Rosin wrote on Thu, Aug 07, 2008 at 02:10:41PM CEST:
2008-08-07 Peter Rosin [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_CHECK_MAGIC_METHOD): Disable nocase
handling for cross compiles.
* Peter Rosin wrote on Sat, Aug 09, 2008 at 11:03:50AM CEST:
Ralf Wildenhues skrev:
Does this BTW mean that the manifest file ends up being part of the .exe
and thus needs not be explicitly installed and uninstalled? That would
be nice.
Yes, the mt command embeds the manifest as a resource,
Ralf Wildenhues wrote:
Oh well; if somebody digs out the auto-import semantics from the list
archives/manuals, feel free to add a note to export.at so that the next
person won't be confused again. (Extra score for putting it in the new
w32 chapter. ;-)
The first issue here is that the
Hi Peter,
* Peter Rosin wrote on Fri, Aug 08, 2008 at 11:42:11AM CEST:
Peter Rosin skrev:
31: export.at:25 Export test
Exporting variables.
This patch fixes the above failure for MSVC. Cygwin/gcc and MinGW are
still happy. Is there any reason for not __declspec(dllimport)ing all
* Peter Rosin wrote on Tue, Aug 05, 2008 at 08:38:28AM CEST:
Ah, ok. That's bad. The misleading name i586-mingw32msvc-gcc caught
me. Again. What in the world is msvc doing in there?
Somebody (Brian Dessent?) explained it nicely, recently on some mailing
list that I skim; I forgot where,
Hi Peter,
* Peter Rosin wrote on Thu, Aug 07, 2008 at 02:10:41PM CEST:
Peter Rosin skrev:
To fix the test failure on the MinGW cross compile, it might be enough
to disable the nocase stuff in libtool.m4 for cross compiles (take the
default branch in the case $host_os statement, near the end
Hi Peter,
* Peter Rosin wrote on Thu, Aug 07, 2008 at 10:10:29AM CEST:
The previous patch was not enough, program linking happened in more than
one place. Here's a new patch that fixes that and also adds the
postlink_cmds variable as mentioned above.
This patch actually fixes all mainfest
Ralf Wildenhues skrev:
* Peter Rosin wrote on Tue, Aug 05, 2008 at 08:38:28AM CEST:
Ah, ok. That's bad. The misleading name i586-mingw32msvc-gcc caught
me. Again. What in the world is msvc doing in there?
Somebody (Brian Dessent?) explained it nicely, recently on some mailing
list that I
Ralf Wildenhues skrev:
Hi Peter,
* Peter Rosin wrote on Thu, Aug 07, 2008 at 10:10:29AM CEST:
The previous patch was not enough, program linking happened in more than
one place. Here's a new patch that fixes that and also adds the
postlink_cmds variable as mentioned above.
This patch actually
Ralf Wildenhues skrev:
Hi Peter,
* Peter Rosin wrote on Fri, Aug 08, 2008 at 11:42:11AM CEST:
Peter Rosin skrev:
31: export.at:25 Export test
Exporting variables.
This patch fixes the above failure for MSVC. Cygwin/gcc and MinGW are
still happy. Is there any reason for not
Peter Rosin skrev:
Ralf Wildenhues skrev:
Hi Peter,
* Peter Rosin wrote on Fri, Aug 08, 2008 at 11:42:11AM CEST:
Peter Rosin skrev:
31: export.at:25 Export test
Exporting variables.
This patch fixes the above failure for MSVC. Cygwin/gcc and MinGW are
still happy. Is there any
Peter Rosin skrev:
31: export.at:25 Export test
Exporting variables.
This patch fixes the above failure for MSVC. Cygwin/gcc and MinGW are
still happy. Is there any reason for not __declspec(dllimport)ing all
these variables?
Cheers,
Peter
2008-08-08 Peter Rosin [EMAIL PROTECTED]
Peter Rosin skrev:
Peter Rosin skrev:
Ralf Wildenhues skrev:
* Peter Rosin wrote on Tue, Aug 05, 2008 at 10:38:14AM CEST:
29: static.at:68 static linking flags for programs
m-all-static.exe.manifest isn't installed
What does the manifest file do?
The manifest is an XML file that
Peter Rosin skrev:
Ralf Wildenhues skrev:
* Peter Rosin wrote on Mon, Aug 04, 2008 at 03:51:29PM CEST:
Ralf Wildenhues skrev:
I've reformatted tests/nocase.at a bit, and sprinkled in more AT_CHECKs
because the test fails for me on a GNU/Linux - MinGW cross compile
(using
Peter Rosin skrev:
Ralf Wildenhues skrev:
*snip*
Please try the patch below for simplistic at-file support with $NM.
While testing, I set nm_file_list_spec to '@' and always_export_symbols
to yes on GNU/Linux, and saw no test failure, probably because my nm
also understands '@'. :-)
(IOW,
Peter Rosin wrote:
Ah, ok. That's bad. The misleading name i586-mingw32msvc-gcc caught
me. Again. What in the world is msvc doing in there?
I believe this is to denote that it defaults to the MSVCRT runtime, as
opposed to the very old CRTDLL one, which the MinGW toolchain still
provides
Peter Rosin skrev:
Attached, I'll work through all the failures to try to find out why
they fail...
16: duplicate_conv.at:25 duplicate convenience archive names
MS link doesn't have reloadable objects (i.e. like ld -r).
24: link-order.at:26 Link order test.
Exporting int c variable.
* Peter Rosin wrote on Tue, Aug 05, 2008 at 10:38:14AM CEST:
Peter Rosin skrev:
Attached, I'll work through all the failures to try to find out why
they fail...
16: duplicate_conv.at:25 duplicate convenience archive names
MS link doesn't have reloadable objects (i.e. like ld -r).
Should
Ralf Wildenhues skrev:
Hi Peter,
yeah, replying to a mail that's 5 months old:
* Peter Rosin wrote on Tue, Mar 04, 2008 at 11:23:48AM CET:
I have no problems with this patch series on either mingw, nor
cygwin.
Great. I've rebased your patches against current git Libtool,
and put them in a
* Peter Rosin wrote on Mon, Aug 04, 2008 at 03:51:29PM CEST:
Ralf Wildenhues skrev:
I've reformatted tests/nocase.at a bit, and sprinkled in more AT_CHECKs
because the test fails for me on a GNU/Linux - MinGW cross compile
(using i586-mingw32msvc-gcc):
libFOO is found but -lfoo is not
Hi Peter,
yeah, replying to a mail that's 5 months old:
* Peter Rosin wrote on Tue, Mar 04, 2008 at 11:23:48AM CET:
I have no problems with this patch series on either mingw, nor
cygwin.
Great. I've rebased your patches against current git Libtool,
and put them in a git branch, named
Follow-up Comment #4, patch #6448 (project libtool):
Peter, I've installed that patched libtool system-wide on gentoo/x86_64
laptop on which I'm doing my current gstreamer development, I'll be re-libtool
everything with it and will report any issues.
Follow-up Comment #2, patch #6448 (project libtool):
Hi, I'd like to give my feedback on these 7 patches (applied against trunk
svn).
They work amazingly well, I have been compiling gstreamer and dependencies
under msys using msvc... and I had to remove all the 'hacks' I previously
added to the
On Sat, 8 Mar 2008, Edward Hervey wrote:
Hi, I'd like to give my feedback on these 7 patches (applied against trunk
svn).
Thanks for the useful feedback. This is good news.
Awesome work ! I don't know what more is needed to push these patches in, if
you need more feedback, logs, etc...
Follow-up Comment #3, patch #6448 (project libtool):
Thanks very much for the feedback,
I'm glad to hear about the success! Previously there has been requests to
test how this patch series behaves on other systems (which are not supposed to
be affected). So, you can help by checking for
Follow-up Comment #1, patch #6448 (project libtool):
I have no problems with this patch series on either mingw, nor
cygwin.
I have not found a functioning cccl to test with. I have tried
both cccl 0.03 as found on sf.net and cccl 0.05 as found on
http://tsunanet.net/~tsuna/cccl
Niether cccl
75 matches
Mail list logo
