Re: [Mingw-w64-public] What is the purpose of intrin.h?
> Code looks ok. I have no objections.
So far so good then. But I do have a question.
In Winnt.h, there is code like this:
#ifdef __CYGWIN__
# if defined(__cplusplus)
extern "C" {
# endif
# include
# if defined(__cplusplus)
}
# endif
#else /* !__CYGWIN__ */
# include
#endif /* __CYGWIN__ */
Since all the intrinsics are already defined in intrin.h, they don't
need to be defined again in winnt.h. UNLESS, cygwin is defined, which
skips intrin.h. So, I was merrily moving the intrinsic definitions that
are already in winnt.h up into the cygwin-only part of the #if, when I
realized something odd: This #if block is only in place for __x86_64,
not for _X86_. Given how instrinsics work in MSVC, this seems a little odd.
As I consider how I want to deal with this, I DON'T want to just copy
the entire block from the x64 to the x86. It's bad enough we are
duplicating these definitions without triplicating them. Since MSVC's
winnt.h doesn't #include intrin.h at all, I (briefly) considered
removing it from this file as well. But it seemed too likely to create
compatibility issues.
So, unless someone gives me a reason to do something else, I intend to
move this block (and all of the winnt.h intrinsics I've added to it) up
out of the x64 #if block, so it will apply to both x86 and x64.
I have modified the other intrinsics for which I have recently submitted
patches to use this approach.
It all compiles, but I'm doing more testing before I'll be ready to
share it.
dw
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] different attempts to enable C++ threads in gcc-4.8.0
2013/6/20 koala01 > Hello, > First, i would like to special thanks to ruben for its effort to provide > the correct C++11 thread support. > > His x86_64-w64-mingw32-gcc-4.8-stdthread-win64_rubenvb personnal build > has me helped a lot to find the better gcc compilation options. > > But this work has, for me, one significant problems: > > - boost compilation fails when build process try to compile some > boost.math files with just a message box like "cc1plus has stopped to > work" (very explicit, isn't it ?) > > I then made different attempts to fix this issue. > > Configure options for Gcc are, more or less, allways the same and looks > like > ..//configure --prefix=/mingw --with-sysroot=/mingw \ > --build=x86_64-w64-mingw32 --disable-nls --enable-shared --enable-static \ > --enable-threads=posix --enable-libstdcxx-threads --enable-libstdcxx-time \ > --disable-win32-registry --enable-libgomp > --enable-version-specific-runtime-libs \ > --with-host-libstdcxx='-static -static-libstdc++ -static-libgcc -lstdc++ > -lm' --disable-werror > > If i change the --enable-treads=posix with --enable-threads=win32 (or > just remove this option), boost compiles fine, but C++11 threads support > is disable, whatever i do for other options > > If i remove the --disable-werror option and add the --disable-bootstrap > one, boost compiles fine, but ONLY if Gcc has been compiled with a 32 > bit Gcc compiler. > > The use of different possibilities for --enable/disable-shared > --enable/disable-static doesn't fix the issue. > > Different kinds of attempts with --with-boot-ldflags --with-boot-libs, > including trying to link explicitly with static version of winpthread, > doesn't fix the issue. > > What do i wrong? > > I don't know what to try more to having a full feature x86_64 hosted Gcc > version with C++11 support being able to compile boost. > And i don't know where to go to try to fix this problem in the code. > > Note: > - pthreadGC2.dll presence (or absence) doesn't matter for compiling with > a 32 bits gcc version. > - i didn't try to provide some pthreadGC2 dll when compiling > - My system is a windows vista, fully up-to-dated > - one of gcc -v sent (when no bootstraped build works): > Using built-in specs. > COLLECT_GCC=c:\tempgcc\bin\gcc.exe > > COLLECT_LTO_WRAPPER=c:/tempgcc/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.exe > Target: mingw32 > Configured with: ../gcc-4.7.2/configure > --enable-languages=c,c++,ada,fortran,objc,obj-c++ \ > --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp \ > --disable-win32-registry --enable-libstdcxx-debug > --disable-build-poststage1-with-cxx \ > --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw > Thread model: win32 > gcc version 4.7.2 (GCC) > > Note: source versions. > My different attempts have been done with following versions: > binutils: 2.23.52 (from FTP) > mingw-w64 stuffs (crt, headers, winpthreads): checked out from svn/trunk > (last attempt at rev 5882, but tried many revision before) > Gcc: 4.8.1_release (rev 199526) and development version checked out from > svn (last attempt at 200172) > gmp: 5.1.2 > mpfr: 3.1.2 > mpc: 1.0 > isl: 0.11.2 > cloog: 0.18.0 > > Excuse me for my bad english, my mother language is french > > >From what I can tell, the Boost.Math issue is a problem for all GCC 4.8.0's: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 You can work around this by using pch=off when invoking b2/bjam. No need to recompile GCC. Also, and this is a more general announcement: since mingw-builds have done and still are doing such a nice job in providing fast and qualitative builds of GCC with MinGW-w64 is all kinds of configurations, please use their excellent binaries: http://sourceforge.net/projects/mingwbuilds/files/?source=navbar I see no reason and moreover don't have the will to continue building GCC myself. Cheers, Ruben > > > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] different attempts to enable C++ threads in gcc-4.8.0
Hello, First, i would like to special thanks to ruben for its effort to provide the correct C++11 thread support. His x86_64-w64-mingw32-gcc-4.8-stdthread-win64_rubenvb personnal build has me helped a lot to find the better gcc compilation options. But this work has, for me, one significant problems: - boost compilation fails when build process try to compile some boost.math files with just a message box like "cc1plus has stopped to work" (very explicit, isn't it ?) I then made different attempts to fix this issue. Configure options for Gcc are, more or less, allways the same and looks like ..//configure --prefix=/mingw --with-sysroot=/mingw \ --build=x86_64-w64-mingw32 --disable-nls --enable-shared --enable-static \ --enable-threads=posix --enable-libstdcxx-threads --enable-libstdcxx-time \ --disable-win32-registry --enable-libgomp --enable-version-specific-runtime-libs \ --with-host-libstdcxx='-static -static-libstdc++ -static-libgcc -lstdc++ -lm' --disable-werror If i change the --enable-treads=posix with --enable-threads=win32 (or just remove this option), boost compiles fine, but C++11 threads support is disable, whatever i do for other options If i remove the --disable-werror option and add the --disable-bootstrap one, boost compiles fine, but ONLY if Gcc has been compiled with a 32 bit Gcc compiler. The use of different possibilities for --enable/disable-shared --enable/disable-static doesn't fix the issue. Different kinds of attempts with --with-boot-ldflags --with-boot-libs, including trying to link explicitly with static version of winpthread, doesn't fix the issue. What do i wrong? I don't know what to try more to having a full feature x86_64 hosted Gcc version with C++11 support being able to compile boost. And i don't know where to go to try to fix this problem in the code. Note: - pthreadGC2.dll presence (or absence) doesn't matter for compiling with a 32 bits gcc version. - i didn't try to provide some pthreadGC2 dll when compiling - My system is a windows vista, fully up-to-dated - one of gcc -v sent (when no bootstraped build works): Using built-in specs. COLLECT_GCC=c:\tempgcc\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/tempgcc/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.7.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ \ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp \ --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1-with-cxx \ --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.7.2 (GCC) Note: source versions. My different attempts have been done with following versions: binutils: 2.23.52 (from FTP) mingw-w64 stuffs (crt, headers, winpthreads): checked out from svn/trunk (last attempt at rev 5882, but tried many revision before) Gcc: 4.8.1_release (rev 199526) and development version checked out from svn (last attempt at 200172) gmp: 5.1.2 mpfr: 3.1.2 mpc: 1.0 isl: 0.11.2 cloog: 0.18.0 Excuse me for my bad english, my mother language is french -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Does anyone use Linux cross-build gcc 4.8 compiler to build native compiler success ?
On Thu, Jun 20, 2013 at 9:11 PM, Earnie Boyd wrote: > On Thu, Jun 20, 2013 at 9:06 AM, Dongsheng Song wrote: >> >> I want to build gcc 4.8 with isl and cloog, can I put isl and cloog >> to gcc/branches/gcc-4_8-branch/ like gmp/mpfr/mpc ? >> > > You should be able to determine that by looking at the top level > configure script. IIRC, it will look for other configure scripts in > the sub-directories. The issue will be prerequisite ordering. > Thanks, I see: $ grep ^host_libs gcc-4_7-branch/configure gcc-4_8-branch/configure gcc-4_7-branch/configure:host_libs="intl libiberty opcodes bfd readline tcl tk itcl libgui zlib libcpp libdecnumber gmp mpfr mpc ppl cloog libelf libiconv" gcc-4_8-branch/configure:host_libs="intl libiberty opcodes bfd readline tcl tk itcl libgui zlib libbacktrace libcpp libdecnumber gmp mpfr mpc isl cloog libelf libiconv" -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Does anyone use Linux cross-build gcc 4.8 compiler to build native compiler success ?
2013/6/20 Ruben Van Boxem > 2013/6/20 Earnie Boyd > >> On Thu, Jun 20, 2013 at 9:06 AM, Dongsheng Song wrote: >> > >> > I want to build gcc 4.8 with isl and cloog, can I put isl and cloog >> > to gcc/branches/gcc-4_8-branch/ like gmp/mpfr/mpc ? >> > >> >> You should be able to determine that by looking at the top level >> configure script. IIRC, it will look for other configure scripts in >> the sub-directories. The issue will be prerequisite ordering. >> > > GCC's build is capable of ordering them just fine. If it wouldn't order > them correctly, what would be the point. > > All the subdirectories that in theory can be built in-tree are listed here: > https://github.com/mirrors/gcc/blob/master/configure#L2749 > > I tried to get this setup working for > ... a broad number of hosts, but ultimately gave up because frankly, it was a bad idea to begin with. Just build everything up front (unless your really want to bootstrap everything at once, including the prerequisites). Ruben > >> -- >> Earnie >> -- https://sites.google.com/site/earnieboyd >> >> >> -- >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> > > -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Does anyone use Linux cross-build gcc 4.8 compiler to build native compiler success ?
2013/6/20 Earnie Boyd > On Thu, Jun 20, 2013 at 9:06 AM, Dongsheng Song wrote: > > > > I want to build gcc 4.8 with isl and cloog, can I put isl and cloog > > to gcc/branches/gcc-4_8-branch/ like gmp/mpfr/mpc ? > > > > You should be able to determine that by looking at the top level > configure script. IIRC, it will look for other configure scripts in > the sub-directories. The issue will be prerequisite ordering. > GCC's build is capable of ordering them just fine. If it wouldn't order them correctly, what would be the point. All the subdirectories that in theory can be built in-tree are listed here: https://github.com/mirrors/gcc/blob/master/configure#L2749 I tried to get this setup working for > > -- > Earnie > -- https://sites.google.com/site/earnieboyd > > > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Does anyone use Linux cross-build gcc 4.8 compiler to build native compiler success ?
On Thu, Jun 20, 2013 at 9:06 AM, Dongsheng Song wrote: > > I want to build gcc 4.8 with isl and cloog, can I put isl and cloog > to gcc/branches/gcc-4_8-branch/ like gmp/mpfr/mpc ? > You should be able to determine that by looking at the top level configure script. IIRC, it will look for other configure scripts in the sub-directories. The issue will be prerequisite ordering. -- Earnie -- https://sites.google.com/site/earnieboyd -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Does anyone use Linux cross-build gcc 4.8 compiler to build native compiler success ?
On Thu, Jun 20, 2013 at 7:59 PM, Dongsheng Song
wrote:
> On Thu, Jun 20, 2013 at 7:03 PM, Christer Solskogen
> wrote:
>> Dongsheng Song writes:
>>
>> Looks fine to me. But I wonder why you build gmp, mpc and mpfr seperatly. You
>> can just run the gcc/contrib/download_prerequisites script.
>> Can you post config.log for the native compiler? I have my own set of scripts
>> which does almost the same as you and I have no problem building 4.8.
>>
Yes, I can confirmed that put gmp, mpfr and mpc to
gcc/branches/gcc-4_8-branch/, gcc 4.8 native compiler can be compiled
successfully.
But why I can not use '--with-gmp=${SYS_3RD_ROOT}
--with-mpfr=${SYS_3RD_ROOT} --with-mpc=${SYS_3RD_ROOT}' ?
I want to build gcc 4.8 with isl and cloog, can I put isl and cloog
to gcc/branches/gcc-4_8-branch/ like gmp/mpfr/mpc ?
>
> Please see the attachment for the following files:
>
> ./config.log
> ./libiberty/config.log
> ./fixincludes/config.log
> ./intl/config.log
> ./lto-plugin/config.log
> ./zlib/config.log
> ./build-x86_64-unknown-linux-gnu/libiberty/config.log
> ./build-x86_64-unknown-linux-gnu/fixincludes/config.log
> ./libbacktrace/config.log
> ./libdecnumber/config.log
> ./libcpp/config.log
> ./gcc/config.log
>
> Regards,
> Dongsheng
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] WIDL feature requests
2013/6/17 Geoffroy Couprie :
> Hi,
>
> I am currently working on writing the IDL files for new WinRT interfaces
> (mostly Windows.Storage and Windows.Foundation for now), and there are a few
> things I would need to make it work. Right now, I can comment out the
> problematic argument types and replace them with IInspectable (after all,
> they're all just pointers), but it would be useful for future idl writing to
> implement those features:
>
> # Struct declaration
>
> When I declare structs at the beginning of the file, like:
> namespace Windows {
> namespace Foundation {
> struct Datetime;
> }
> }
>
> It works if I define the struct later, but not if I am importing the struct
> from another idl, with the message: error: syntax error, unexpected ';',
> expecting '{'
>
> If I don't declare it in the importing file, I can still use the type
> without any problem, though.
Yes, that looks like a quirk in widl.
> # Delegates
> Some interfaces are declared as delegate, like this:
> namespace Windows { namespace Foundation { delegate TypedEventHandler; } }
>
> It looks like they are interfaces inheriting from IUnknown with the method
> "HRESULT Invoke()".
Hmm, AFAIU winrt API nearly everything is derived by IInspectable
class, which itself is derieved from IUnknown (as all DCOM-object are
AFAIK).
> # Templates
> New interfaces with parametric types were introduced. They are defined like
> this:
> generic
> interface IAsynOperation : AsyncInfo {
> [propput] HRESULT Completed(AsyncActionCompletedHandler* handler);
> [propget] HRESULT Completed(AsyncActionCompletedHandler** handler);
> TResult* GetResults();
> }
Hmm, that's an parser extension. Shouldn't be too hard.
> And when it is used in another IDL file, it is declared like this:
> interface Windows.Foundation.IAsyncOperation;
>
> And used directly like this: Windows.Foundation.IAsyncOperation
>
> No C headers are generated for this, only C++ headers, using templates. This
> is probably the most complex part to implement (a lot of C++ classes are
> defined to make this work).
Well, that is not really true ... at least not in all cases. But I
admit that API looks pretty C++-centric. So we have some freedom in
allowing C-typing too ;)
> # Cyclic dependencies
> Some interfaces can depend on one another, like IAsyncAction and
> AsyncActionCompletedHandler:
>
> interface IASyncAction : IInspectable {
> [propput] HRESULT Completed(AsyncActionCompletedHandler* handler);
> [propget] HRESULT Completed(AsyncActionCompletedHandler** handler);
> HRESULT GetResults();
> }
Hmm, AFAIR has IAsyncInfo the object-id uuid
(0036---C000-0046),.
IInspectable has GUID of uuid (AF86E2E0-B12D-4c6a-9c5a-D7AA65101E90).
You meant for sure IAsyncAction, aren't you? And it has GUID of uuid
(5a648006-843a-4da9-865b-9d26e5dfad7b).
> interface AsyncActionCompletedHandler : IUnknown {
> HRESULT Invoke(IAsyncAction *asyncAction, AsyncStatus status);
> }
>
> Right now, it fails with the message: error: write_ip_tfs: interface
> IAsyncAction missing UUID
See above.
> # Empty interfaces
> I don't know if I read the documentation wrong, but for
> Windows.Foundation.Collections.IPropertySet, there are no methods defined
> (because it inherits methods from two other interfaces. So if I declare it
> like this (I know it inherits directly from something else than
> IInspectable):
> interface IPropertySet : IInspectable {
> }
The point here is that widl right now doesn't support dot-joined
names. This is something parser needs to be extended. AFAICS is this
dot-syntax used for namespace ... but sometimes it looks to me like it
is also used as abbreviation for namespace-chains ...
> and here is the message I get: error: syntax error, unexpected $end,
> expecting '{'
Hmm, might be caused by missing uuid for IInspectable ...
> I have tried to patch widl, but my parser fu is not very strong :(
>
> I'm willing to test any patch for these features, though.
>
> Best regards,
>
> --
> Geoffroy Couprie
>
> http://geoffroycouprie.com
> http://pilotssh.com
Cheers,
Kai
PS: Sorry for the late comment.
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] What is the purpose of intrin.h?
2013/6/19 dw :
> So, having heard nothing back on this topic, I've decided to just try it and
> see how it looks.
Thanks.
> Below are the proposed contents of the new file intrin-impl.h, which gets
> included at the bottom of intrin.h. It's still a little rough, but it
> should be enough to decide if I'm heading in the right direction. My plan
> (pending feedback) is to see about migrating the rest of my most recent
> patch attempt (__faststorefence et al) to using this approach. Nothing
> tests ideas like using them.
>
>
>
> /* To use the implementations in this file, you would normally just #include
>
>This will define inlines for all intrinsics.
> */
>
> /* To implement the library versions of the functions in this file, add code
> like this
>to the appropriate c file in mingw-w64-crt\intrincs:
>
>#define __INTRINSIC_ONLYSPECIAL
>#define __INTRINSIC_SPECIAL___stosb // Specify the function to
> implement
>
>#include
> */
>
> /* To add an implementation for a new intrinsic to this file, first make
> sure the definition exists in intrin.h.
>The assumption is that intrin.h will ONLY contain definitions for MSVC's
> intrinsic functions. Next,
>use this outline when adding definitions to this file:
>
> #if __INTRINSIC_PROLOG(__faststorefence) // Checks to see if needed
>
> __INTRINSICS_USEINLINE // Optional. May be omitted (for example when using
> #define)
>
>
> #endif // __INTRINSIC_PROLOG
> */
>
> #ifndef _INTRIN_IMPL_
> #define _INTRIN_IMPL_
>
> #include
>
> /* The logic for this macro is:
>(if we are not just defining special OR (we are defining special AND this
> is one of the ones we are defining))
> */
> #define __INTRINSIC_PROLOG(name) (!defined (__INTRINSIC_ONLYSPECIAL)) ||
> (defined (__INTRINSIC_ONLYSPECIAL) && defined(__INTRINSIC_SPECIAL_ ## name))
>
> #ifdef __INTRINSIC_ONLYSPECIAL
> #define __INTRINSICS_USEINLINE
> #else
> #define __INTRINSICS_USEINLINE __MINGW_INTRIN_INLINE
> #endif
>
> #ifdef __x86_64__
>
> #if __INTRINSIC_PROLOG(__faststorefence)
> __INTRINSICS_USEINLINE void __faststorefence(void) {
> _mm_sfence();
> }
> #endif // __INTRINSIC_PROLOG
>
> #endif // __x86_64__
>
> #if __INTRINSIC_PROLOG(__int2c)
> __INTRINSICS_USEINLINE void __int2c(void) {
> __buildint(0x2c);
> }
> #endif // __INTRINSIC_PROLOG
>
> #endif // _INTRIN_IMPL_
>
Code looks ok. I have no objections.
Thanks,
Kai
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Does anyone use Linux cross-build gcc 4.8 compiler to build native compiler success ?
Dongsheng Song writes: Looks fine to me. But I wonder why you build gmp, mpc and mpfr seperatly. You can just run the gcc/contrib/download_prerequisites script. Can you post config.log for the native compiler? I have my own set of scripts which does almost the same as you and I have no problem building 4.8. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] link msvcr100 problem under mingw
On Thu, Jun 20, 2013 at 2:31 PM, zhangxinghai wrote: > Hello > I write a test helloworld program.I want to link it against msvcr100.My > enviroment is > os:xp sp3 > mingw64 version:ruben build target win32 > I compile the program as > gcc -o hello.exe main.cpp -lmsvcr100. > > My problem is when I add -lmsvcr100 switch,I run the dependency walker on > the hello.exe,I see it depends on both msvcrt.dll(c:\windows\system32) and > msvcr100.dll. > But If I write the same program under vs 2010,the output hello.exe only > depends on msvcr100.dll > > Is is possible for mingw64 to generate executable file only depend on > msvcr100.dll? Or do I do something wrong ? > Yes. If you see the verbose output: crt2.o crtbegin.o cc1woImu.o -lmsvcr100 -lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt crtend.o You can see '-lmsvcrt' in the library list. So you can do this: g++ -dumpspecs > msvcr100.spec Edit msvcr100.spec, change '-lmsvcrt' to '-lmsvcr100', then just execute: g++ -specs=msvcr100.spec -s -O2 -o hello.cpp.exe hello.cpp Then 'hello.cpp.exe' only depend on 'msvcr100.dll'. But 'hello.cpp.exe' depend on 'libstdc++-6.dll', you must compile your self to avoid 'libstdc++-6.dll' depend on 'msvcrt.dll' too. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
