Re: [Mingw-w64-public] LLVM libc++ build with gcc

2018-12-22 Thread Teemu Nätkinniemi 
You should link msvcrt as well.

su 23. jouluk. 2018 klo 2.25 Maarten Verhage (m_r_verh...@hotmail.com)
kirjoitti:
>
> Hi Liu, Martin and others,
>
> With both of you we mentioned the idea of building the LLVM libc++ with
> mingw gcc on Windows. This in order to get C++11 functionality in the Mingw
> win32-seh variant. Which in turn could be used to build LLVM and clang.
>
> I hope this LLVM related question is suitable for this mailing list. Still
> it depend strongly on mingw64.
>
> I was able to get the static library libc++.a out of it. My cmake command
> line was:
>
> cmake -G "MinGW Makefiles" ^
> -DCMAKE_BUILD_TYPE=Release ^
> -DLIBCXX_HAS_WIN32_THREAD_API=ON ^
> -DLIBCXX_ENABLE_SHARED=OFF ^
> -DLIBCXX_ENABLE_STATIC=ON ^
> -DLIBCXX_ENABLE_EXCEPTIONS=ON ^
> -DCMAKE_CXX_COMPILER=g++ ^
> -DCMAKE_CXX_FLAGS="-D_LIBCPP_BUILDING_LIBRARY -D_WIN32_WINNT=0x0600" ^
> -DCMAKE_INSTALL_PREFIX="t:/libcxx_install/release" ^
> -S..\libcxx ^
> -BT:\libcxx_build > libcxx_cmake_result.txt 2>&1
>
> Then I build the makefile. The result of that is in the attachment
> libcxx_build_result.txt. Would you be willing to check if these compile
> warning look harmless? I didn't build libc++abi yet. Because I'm missing the
> knowledge to see what role it has.
>
> I wasnt sure where I would need to start with the official LLVM tests of
> libc++ using LIT. Do you know how I would need to setup the test environment
> in pure Windows?
>
> So instead I set out to write a little program and see if I could manage to
> tell gcc to use the LLVM libc++ and see if it compiles and links correctly.
>
> #include 
> #include 
> #include 
> // include string to see if it actually uses the llvm libc++ library
> #include 
>
> int main()
> {
>   std::string str("Hello, world\n");
>
>   printf( str.c_str() );
>   getchar();
>   return 0;
> }
>
> Here is my makefile:
> FLAGS = -std=c++14 -pedantic -Wextra -Wlogical-op
> INCPATH_LLVM_LIBCXX = -I"C:\dev\libcxx_install\release\include\c++\v1"
> LIBPATH_LLVM_LIBCXX = -L"C:\dev\libcxx_install\release\lib"
> MINGW64_PATH =
> "C:\dev\x86_64-8.1.0-release-win32-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32"
> INCPATH_WIN = -I"$(MINGW64_PATH)\include"
> LIBPATH_WIN = -L"$(MINGW64_PATH)\lib"
>
> LIBSWIN = -l:libkernel32.a -l:libuser32.a -l:libshell32.a -l:libadvapi32.a\
>  -l:libws2_32.a -l:liboleaut32.a -l:libimm32.a -l:libwinmm.a -l:libole32.a\
>  -l:libuuid.a -l:libopengl32.a -l:libole32.a -l:libgdi32.a
>
> all: test.exe
>
> test.exe : test.o
>  g++ -v -nodefaultlibs -static -mconsole test.o
> $(LIBPATH_LLVM_LIBCXX) -l:libc++.a -l:libgcc_s.a -l:libgcc.a
> $(LIBSWIN) -Wl,-Map,test_map.txt -o test.exe > link_result.txt 2>&1
>
> test.o : test.cpp
>  g++ -v -c -nostdinc++ -nostdlib $(INCPATH_LLVM_LIBCXX) $(FLAGS) test.cpp
>
> clean:
>  del test.o test.exe
>
> It seems to compile but it fails with link. Please see link_result.txt. A
> whole bunch of undefined references. Some specific to mingw as well as the
> standard C library. But I could not find libc.a in the mingw build.
>
> On the LLVM documentation website:
> https://libcxx.llvm.org/docs/UsingLibcxx.html#using-libc-with-gcc
> there is a section called “Using libc++ with GCC” which demonstrates the
> static gcc libraries to link with. These
> are: -lc++ -lc++abi -lm -lc -lgcc_s –lgcc.
>
> But I cannot find a libc.a or a libm.a library files in the mingw64 builds
> like x86_64-8.1.0-release-win32-seh-rt_v6-rev0 for example.
>
> My questions are:
>
> What should I do to make this little program to link?
> Is there an internet resource where I can learn what all the mingw64
> supplied static libraries are used for? Like libsupc++.a, libgcc_eh.a. And
> where the standard C library is hidden?
>
> Thanks a lot for your time!
>
> Best regards,
> Maarten Verhage
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] how to remove libgcc_s_sjlj-1.dll dependency

2014-05-05 Thread Teemu Nätkinniemi 
On 5.5.2014 10:19, YIRAN LI wrote:
> I'm building an opensource project on mingw32 and found the generated
> dll depends on  libgcc_s_sjlj-1.dll. The function referenced is __divdi3.
>
> I tried to add ldflags = -static- libgcc, but seems it doesn't work.
>
> Could any one let me know how can I get rid of this dependency?

This should work:

CC='gcc -static-libgcc -static-libstdc++' CXX='g++ -static-libgcc 
-static-libstdc++' ./configure



--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Why is MSYS2 Git so slow?

2013-12-31 Thread Teemu Nätkinniemi 
On 31.12.2013 18:06, Ray Donnelly wrote:
> I think someone should take the time to look at optimizing the file io
> in cygwin as I expect that's the real cause of slowness in msys2 git.

Have you tested it with Cygwin to determine if MSYS2 or Cygwin is the cause?


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] A small major sbuild update

2013-10-23 Thread Teemu Nätkinniemi 
On 23.10.2013 21:09, LRN wrote:
>> This fixed the problem but using vanilla MSYS2 with Autoconf 2.69
>> doesn't have this issue.
> I've set up bash_msys.bat to set SHELLOPTS=igncr.

Removing the line fixed the issue.

AFAIK, sbuild is by far the most complete method of building a 
Mingw/MSYS2 toolchain on Windows host. Thanks a lot for your hard work!


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] A small major sbuild update

2013-10-23 Thread Teemu Nätkinniemi 
On 23.10.2013 20:29, LRN wrote:
> Alternatively you can do autoreconf, which will (or should, at least)
> rebuild configure with patched status.m4 that you get from the autoconf
> package that sbuild installed.

This fixed the problem but using vanilla MSYS2 with Autoconf 2.69 
doesn't have this issue.


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] A small major sbuild update

2013-10-23 Thread Teemu Nätkinniemi 
On 21.10.2013 23:01, LRN wrote:

> sbuild[1] was bumped to 3.2 due to the basic toolchain update - mingw

This is the first version of sbuild I've tried and cannot configure 
anything as I get the following error every time and cannot figure out 
what is causing the problem. The system is Windows 8.1 x64 and there are 
no BLODA issues. Sbuild itself builds without any issues.

config.status: creating Makefile
gawk: ./confmUDjn0/subs.awk:1: BEGIN {\r
gawk: ./confmUDjn0/subs.awk:1:^ backslash not last character on line
gawk: ./confmUDjn0/subs.awk:1: BEGIN {\r
gawk: ./confmUDjn0/subs.awk:1:^ syntax error
config.status: error: could not create Makefile

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2

2013-08-26 Thread Teemu Nätkinniemi 
On 26.8.2013 18:38, Rainer Emrich wrote:
> Am 26.08.2013 17:27, schrieb Alexpux:
>>
>> 26.08.2013, в 19:17, Rainer Emrich  
>> написал(а):
>>> Did you ever tried expect? For me it doesn't work, always returns 
>>> immediately
>>> without any output.
>> How to reproduce problem?
> "expect -v" should output the expect version, it doesn't, no output at all.
> "expect" should give a expect shell with an expect prompt, it doesn't.

Is tcsh working normally? This might be unrelated but MSYS1 behaved 
exactly this way when trying to get Expect working.


--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2

2013-07-10 Thread Teemu Nätkinniemi 
On 9.7.2013 20:33, Alexey Pavlov wrote:
>
>
>
> 2013/7/9 Teemu Nätkinniemi mailto:tnatk...@gmail.com>>
>
> On 9.7.2013 20:21, Alexey Pavlov wrote:
>  > Upload new MSYS2 snapshots:
>
> Does this already work with win32 tools?
>
> Yes we successfully using it with native Mingw-w64 toolchains for
> building software.

Looks like it is working! I actually tried using the old /mingw method 
and got it working after setting C_INCLUDE_PATH etc. to point to correct 
locations. I am building Qt 5.1 at the moment and it seems to work 
except I had to increase Ruby's stacksize.


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2

2013-07-09 Thread Teemu Nätkinniemi 
On 9.7.2013 20:21, Alexey Pavlov wrote:
> Upload new MSYS2 snapshots:

Does this already work with win32 tools?


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] segfault

2013-04-03 Thread Teemu Nätkinniemi 
On Wed, Apr 3, 2013 at 2:48 PM, Ahso Aa  wrote:

>  I've recompiled with the new gdbinit but still the same. Also tried with
> -m32 and 32bit libs but it says skipping incompatible libs.
> Thanks
>
>  --
> Microsoft Windows [Version 6.0.6002]
> Copyright (c) 2006 Microsoft Corporation. Alle Rechte vorbehalten.
>
> C:\Users\michael>f:
>
> F:\>cd X*o
>
> F:\X-Plane 10 Demo>gdb X-Plane.exe
> GNU gdb (GDB) 7.5.1
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-w64-mingw32".
> For bug reporting instructions, please see:
> ...
> Reading symbols from F:\X-Plane 10 Demo\X-Plane.exe...(no debugging
> symbols foun
> d)...done.
> (gdb) run
> Starting program: F:\X-Plane 10 Demo\X-Plane.exe
> [New Thread 3352.0xd0c]
> [New Thread 3352.0xfd0]
> [New Thread 3352.0x500]
> [New Thread 3352.0x77c]
> [New Thread 3352.0xc44]
> [New Thread 3352.0x364]
> [New Thread 3352.0xc88]
> [New Thread 3352.0x11c]
> [New Thread 3352.0xca8]
> [New Thread 3352.0xd20]
> [New Thread 3352.0x544]
> [New Thread 3352.0xdc8]
> [New Thread 3352.0xdb8]
> [New Thread 3352.0xd7c]
> [New Thread 3352.0xe00]
> [New Thread 3352.0xcf8]
> [New Thread 3352.0xd94]
> [New Thread 3352.0xd28]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x6d48d680 in IMG_Load ()
>from F:\X-Plane 10 Demo\Aircraft\General
> Aviation\PC-12_V3r3\NG\plugins\pc12\
> 64\win.xpl
> (gdb) bt full
> #0  0x6d48d680 in IMG_Load ()
>from F:\X-Plane 10 Demo\Aircraft\General
> Aviation\PC-12_V3r3\NG\plugins\pc12\
> 64\win.xpl
> No symbol table info available.
> #1  0x6d4829ef in LoadGLTex(char*, int) ()
>from F:\X-Plane 10 Demo\Aircraft\General
> Aviation\PC-12_V3r3\NG\plugins\pc12\
> 64\win.xpl
> No symbol table info available.
> #2  0x in ?? ()
> No symbol table info available.
> (gdb) q
> A debugging session is active.
>
> Inferior 1 [process 3352] will be killed.
>
>

Might be a problem with your toolchain? Using a debug build of SDL might be
more informative.

Are you trying to build a x64 version? In that case don't use -m32 flag.
--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Cross-compiling BASH

2013-02-20 Thread Teemu Nätkinniemi 
On 14.2.2013 8:32, Алексей Павлов wrote:
> Hi!
>
> I work on MSYS2 and now built mingw-msys2 cross compiler. Also I
> successfully build native toolchain for msys2 and some 3rdparty libs.
> Now I need to cross-compiling BASH but I got error on start building:

I had this same problem when trying to cross-compile Cygwin64 Bash and 
the solution was to build it natively.


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] msys ./configure gives error 77, "compiler doesn't generate exe's"

2012-06-11 Thread Teemu Nätkinniemi 
On 11.6.2012 18:48, Earnie Boyd wrote:
> On Sat, Jun 9, 2012 at 4:08 AM, Jim Michaels  wrote:
>> other stuff now compiles just fine (well, except for the ones that are
>> unix-specific like jack audio, and apache modules).  :-(
>>
>> looks like I am not going to be doing much with Jack audio server.
>>
>
> You'll need to figure out how to port these or turn on others ports of
> these packages.  I know apache has Windows builds, I use it, but I use
> someone else's distribution.

Jack has prebuilt binaries for Windows.




--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MinGW-w64 MSYS version questions.

2012-05-15 Thread Teemu Nätkinniemi 
On 15.5.2012 16:02, MARTIN Pierre wrote:

> i'm a bit confused, and would like to hear from you all: what do
> you usually do, as a rule of thumb, when requiring another
> package? Is there an un-official (Off-list if needed) where i can get
> something similar to MinGW-Get, but for the MinGW-w64 version
> of MSYS (i remember that i was answered that such repository
> doesn't exists, i'm asking 3 weeks later, and off-list if needed)?

I personally use Ralph Engels' environment which has pretty much 
everything I need, except Qt. It is a combination of MSYS and MinGW-w64. 
I think you can safely replace the GCC Ralph uses with Ruben's GCC.

http://sourceforge.net/projects/cbadvanced/

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MinGW-w64 support added for blender

2012-04-25 Thread Teemu Nätkinniemi 
On 25.4.2012 0:21, Antony Riakiotakis wrote:

> MinGW support has always been optional for blender, official binaries
> are built on MSVC 2008. We do have some users and developers compiling
> with MinGW though. A few obstacles to get it becoming a true
> alternative to MSVC on the developer level is the dependence of python
> on MSVC runtime, especially for debug libraries, and the reliance of
> the NVIDIA CUDA compiler that we use for GPU acceleration on the
> existence of MSVC on the system. And the speed of compilation which is
> terrible compared to linux gcc (I am very curious about the cause for
> that).

If you want faster compiler for MinGW I would suggest a cross-compiler 
on Linux. Most major distros have MinGW and/or MingGW toolchains or you 
can compile one yourself.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Off-topic about Cygwin / MSVC

2012-04-20 Thread Teemu Nätkinniemi 
On 20.4.2012 14:49, MARTIN Pierre wrote:

> Is there anyone aware of some kind of wrapper so i could use the MSVC 
> compiler with either MSYS or cygwin? By that, i mean that i have bash scripts 
> which perform under either linux, macos and windows, and i would like to be 
> able to use them as well in cohesion with the MSVC compiler.

I am not sure at what stage Parity's Cygwin/MSYS support is but you can 
test it:

http://sourceforge.net/projects/parity/

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Static Link libstdc++-6

2012-03-13 Thread Teemu Nätkinniemi 
On 13.3.2012 13:32, Earnie Boyd wrote:
> On Tue, Mar 13, 2012 at 4:54 AM, Kai Tietz  wrote:
>> 2012/3/13 Teemu Nätkinniemi:
>>> On 13.3.2012 10:26, Kyle wrote:
>>>
>>>> I have tried adding -static and -static-libstdc++ to both the LDFLAGS
>>>> and CFLAGS for FFmpeg. I have tried adding them to utvideo as well.
>>>>
>>>> I'm not sure how to force FFmpeg to compile statically, but if anyone
>>>> has any input I would greatly appreciate it!
>>>
>>> Rename libstdc++.dll.a so ld will use libstdc++.a instead.
>>
>> Better and not so hacky way to solve this is to specify option
>> '-static-libstdc++' on link for gcc's frontend.
>
> Not just hacky, the rename of .dll.a to just .a doesn't resolve
> anything and potentially removes the static library that already
> exists.  Such advice should never be given.

I meant renaming libstdc++.dll.a for example to libstdc++.dll.a.donotuse 
so that will force ld to use static version.


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Static Link libstdc++-6

2012-03-13 Thread Teemu Nätkinniemi 
On 13.3.2012 10:26, Kyle wrote:

> I have tried adding -static and -static-libstdc++ to both the LDFLAGS
> and CFLAGS for FFmpeg. I have tried adding them to utvideo as well.
>
> I'm not sure how to force FFmpeg to compile statically, but if anyone
> has any input I would greatly appreciate it!

Rename libstdc++.dll.a so ld will use libstdc++.a instead.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MinGW64 status for use in blender3D

2012-03-11 Thread Teemu Nätkinniemi 
On 12.3.2012 0:54, JonY wrote:
> On 3/12/2012 04:09, Antony Riakiotakis wrote:
>> Hi, thanks for the reply!
>>
>> I know there are nightly and personal builds but was refering to
>> official builds of official releases.
>> Maybe I oversaw them but couldn't locate these in the binary list.
>>
>> About libraries I meant clashes in 32bit vs 64bit libraries when
>> linking with the compilers as the link I have posted reports.
>>
>> Thanks for the configuration, if all else turns out fine I can test this.
>
> I would say the article author has a really screwed up toolchain install
> or is trolling or is clueless about using GCC on Windows.
>
> I don't know why the author has so much problems with 32bit vs 64bit
> DLLs. You don't need to copy any DLLs, or use anything from System32
> (Why did the author do it in the first place??), the import libraries
> are already there.

I saw recently this same method used in some other project.

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problem with compiling x64 version of Stellarium

2012-03-10 Thread Teemu Nätkinniemi 
On 8.3.2012 23:58, JonY wrote:
> On 3/9/2012 05:12, Teemu Nätkinniemi wrote:
>> G:/MinGWx64/msys/1.0/src/stellarium/src/core/StelTexture.hpp:27,
>>from
>> g:/MinGWx64/msys/1.0/src/stellarium/plugins/Satellites/src/Satellite.cpp:26:
>> g:\cbad\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../x86_64-w64-mingw32/include/msxml.h:624:109:
>> error: expected ',' or '...' before numeric constant
>> g:\cbad\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../x86_64-w64-mingw32/include/msxml.h:830:143:
>> error: expected ',' or '...' before numeric constant
>> make[2]: ***
>> [plugins/Satellites/src/CMakeFiles/Satellites-static.dir/Satellite.cpp.obj]
>> Error 1
>> make[1]: ***
>> [plugins/Satellites/src/CMakeFiles/Satellites-static.dir/all] Error 2
>> make: *** [all] Error 2
>
> Likely somebody defined pi as a macro.

I found the offending file 
(stellarium\plugins\Satellites\src\gsatellite\sgp4unit.h). Somebody 
decided to define pi even if the file includes math.h. Replaced all with 
M_PI and now it compiles cleanly. Thanks a lot!


--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Problem with compiling x64 version of Stellarium

2012-03-08 Thread Teemu Nätkinniemi 
Hello!

I've managed succesfully to build x64 version of Stellarium but had to 
fix msxml.h to get it compiling. I am not sure where the problem lies, 
maybe I have to include something? Commenting out the lines with errors 
made the build succeed. I noticed someone else had this same problem 
earlier but didn't post any solution:

https://sourceforge.net/projects/mingw-w64/forums/forum/723798/topic/4798728

The error is as follows:

[ 19%] Building CXX object 
plugins/Satellites/src/CMakeFiles/Satellites-static.dir/Satellite.cpp.obj
In file included from 
g:\cbad\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../x86_64-w64-mingw32/include/urlmon.h:219:0,
  from 
g:\cbad\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../x86_64-w64-mingw32/include/objbase.h:346,
  from 
g:\cbad\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../x86_64-w64-mingw32/include/ole2.h:16,
  from 
g:\cbad\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../x86_64-w64-mingw32/include/windows.h:97,
  from 
G:/cbad/qt-4.8.0-x64/include/QtCore/../../src/corelib/global/qt_windows.h:63,
  from G:/cbad/qt-4.8.0-x64/include/QtCore/qt_windows.h:1,
  from 
G:/cbad/qt-4.8.0-x64/include/QtOpenGL/../../src/opengl/qgl.h:58,
  from G:/cbad/qt-4.8.0-x64/include/QtOpenGL/qgl.h:1,
  from G:/cbad/qt-4.8.0-x64/include/QtOpenGL/QtOpenGL:5,
  from 
G:/MinGWx64/msys/1.0/src/stellarium/src/core/StelTexture.hpp:27,
  from 
g:/MinGWx64/msys/1.0/src/stellarium/plugins/Satellites/src/Satellite.cpp:26:
g:\cbad\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../x86_64-w64-mingw32/include/msxml.h:624:109:
 
error: expected ',' or '...' before numeric constant
g:\cbad\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../x86_64-w64-mingw32/include/msxml.h:830:143:
 
error: expected ',' or '...' before numeric constant
make[2]: *** 
[plugins/Satellites/src/CMakeFiles/Satellites-static.dir/Satellite.cpp.obj] 
Error 1
make[1]: *** 
[plugins/Satellites/src/CMakeFiles/Satellites-static.dir/all] Error 2
make: *** [all] Error 2

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] rubenvb Personal Build

2010-09-24 Thread Teemu Nätkinniemi 
On 24.9.2010 15:17, Earnie wrote:
> Teemu Nätkinniemi wrote:
>>
>> Here's Dejagnu + Expect + Tcl/Tk for Msys. Binaries only as the
>> author never released the sources. I haven't tested it for Mingw
>> targets.
>>
>> http://www.mediafire.com/?gp8xkvej6b68ch8
>>
>
> We should ask the author for the sources and if they cannot be delivered
> report it as a license breech to gnu.org.  Having the source is one of
> the beauties of the GPL.

I tried contacting the original author but he hasn't responded.

I've patched this one myself. And here's the source. Dejagnu and Excpect 
live inside the main tree.

http://www.mediafire.com/?1xt1i5p8o9i4jht


--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-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] rubenvb Personal Build

2010-09-24 Thread Teemu Nätkinniemi 
On 24.9.2010 15:12, Earnie wrote:
> NightStrike wrote:
>> On Thu, Sep 23, 2010 at 8:47 AM, Teemu Nätkinniemi
>>   wrote:
>>>>>>> Can you run the testsuite? (Make -k check)
>>>>>>>
>>>>>>>
>>>>>> I cannot, because MSYS doesn't have the necessary tools. It
>>>>>> apparently only works on Cygwin, which don't have...
>>>>>>
>>>>>
>>>>> What is missing?
>>>>>
>>>>> Earnie
>>>>>
>>>>
>>>> Hi,
>>>>
>>>> gnu expect and runtest. There might be more, but I have not run
>>>> the tests.
>>>
>>> Here's Dejagnu + Expect + Tcl/Tk for Msys. Binaries only as the
>>> author never released the sources. I haven't tested it for Mingw
>>> targets.
>>>
>>> http://www.mediafire.com/?gp8xkvej6b68ch8
>>
>> Built against what version of msys?
>>
>
> If it works for one version of MSYS it should work for all current
> versions.  There have been no ABI changes within the runtime DLL.  You
> would need to rebuild it if you develop for MSYS.
>
> Earnie
>

As I wrote a little earlier, here's a rebuilt version:

http://www.mediafire.com/?2af4e3xybtzynow

--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-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] Msys and Dejagnu

2010-09-24 Thread Teemu Nätkinniemi 

On 23.9.2010 18:43, Teemu Nätkinniemi wrote:

Here's an example logs from building Binutils-2.19.51-1 (Msys)


Here's Dejagnu + Expect + Tcl/Tk patched by me and compiled against Msys 
1.0.15 with GCC 3.4.4. I'll upload sources later as at the moment the 
building needs couple of manual steps and I'll try to figure out a way 
around them. Attached is also new log from earlier Binutils-2.19.51-1 
and this version seems to manage a little better.


This version supports Msys and I am not sure if Dejagnu has to be 
changed to get it supporting Mingw.



http://www.mediafire.com/?2af4e3xybtzynow
Test Run By Teemu on Fri Sep 24 10:15:55 2010
Native configuration is i686-pc-msys

=== binutils tests ===

Schedule of variations:
unix

Running target unix
Using /share/dejagnu/baseboards/unix.exp as board description file for target.
Using /share/dejagnu/config/unix.exp as generic interface file for target.
Using /src/ginu/binutils-2.19.51-1/binutils/testsuite/config/default.exp as 
tool-and-target-specific interface file.
Running /src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/ar.exp ...
/src/ginu/build/binutils/ar rc tmpdir/artest.a 
tmpdir/abcdefghijklmnopqrstuvwxyz1 tmpdir/abcdefghijklmnopqrstuvwxyz2
Executing on host: /src/ginu/build/binutils/ar rc tmpdir/artest.a 
tmpdir/abcdefghijklmnopqrstuvwxyz1 tmpdir/abcdefghijklmnopqrstuvwxyz2   
(timeout = 300)
spawn /src/ginu/build/binutils/ar rc tmpdir/artest.a 
tmpdir/abcdefghijklmnopqrstuvwxyz1 tmpdir/abcdefghijklmnopqrstuvwxyz2 
/src/ginu/build/binutils/ar rc tmpdir/artest.a 
tmpdir/abcdefghijklmnopqrstuvwxyz1 tmpdir/abcdefghijklmnopqrstuvwxyz2
Executing on host: /src/ginu/build/binutils/ar rc tmpdir/artest.a 
tmpdir/abcdefghijklmnopqrstuvwxyz1 tmpdir/abcdefghijklmnopqrstuvwxyz2   
(timeout = 300)
spawn /src/ginu/build/binutils/ar rc tmpdir/artest.a 
tmpdir/abcdefghijklmnopqrstuvwxyz1 tmpdir/abcdefghijklmnopqrstuvwxyz2 
/src/ginu/build/binutils/ar t tmpdir/artest.a
Executing on host: /src/ginu/build/binutils/ar t tmpdir/artest.a   (timeout = 
300)
spawn /src/ginu/build/binutils/ar t tmpdir/artest.a 
FAIL: ar long file names
Executing on host: /src/ginu/build/gas/as-new 
/src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/bintest.s  -o 
tmpdir/bintest.o(timeout = 300)
spawn /src/ginu/build/gas/as-new 
/src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/bintest.s -o 
tmpdir/bintest.o 
/src/ginu/build/binutils/ar rc tmpdir/artest.a tmpdir/bintest.o
Executing on host: /src/ginu/build/binutils/ar rc tmpdir/artest.a 
tmpdir/bintest.o   (timeout = 300)
spawn /src/ginu/build/binutils/ar rc tmpdir/artest.a tmpdir/bintest.o 
/src/ginu/build/binutils/nm-new --print-armap tmpdir/artest.a
Executing on host: /src/ginu/build/binutils/nm-new --print-armap 
tmpdir/artest.a   (timeout = 300)
spawn /src/ginu/build/binutils/nm-new --print-armap tmpdir/artest.a 
FAIL: ar symbol table
Executing on host: /src/ginu/build/gas/as-new 
/src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/bintest.s  -o 
tmpdir/bintest.o(timeout = 300)
spawn /src/ginu/build/gas/as-new 
/src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/bintest.s -o 
tmpdir/bintest.o 
/src/ginu/build/binutils/ar rcT tmpdir/artest.a tmpdir/bintest.o
Executing on host: /src/ginu/build/binutils/ar rcT tmpdir/artest.a 
tmpdir/bintest.o   (timeout = 300)
spawn /src/ginu/build/binutils/ar rcT tmpdir/artest.a tmpdir/bintest.o 
/src/ginu/build/binutils/nm-new --print-armap tmpdir/artest.a
Executing on host: /src/ginu/build/binutils/nm-new --print-armap 
tmpdir/artest.a   (timeout = 300)
spawn /src/ginu/build/binutils/nm-new --print-armap tmpdir/artest.a 
FAIL: ar thin archive
Executing on host: /src/ginu/build/gas/as-new 
/src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/bintest.s  -o 
tmpdir/bintest.o(timeout = 300)
spawn /src/ginu/build/gas/as-new 
/src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/bintest.s -o 
tmpdir/bintest.o 
/src/ginu/build/binutils/ar rc tmpdir/artest.a tmpdir/bintest.o
Executing on host: /src/ginu/build/binutils/ar rc tmpdir/artest.a 
tmpdir/bintest.o   (timeout = 300)
spawn /src/ginu/build/binutils/ar rc tmpdir/artest.a tmpdir/bintest.o 
/src/ginu/build/binutils/ar rcT tmpdir/artest2.a tmpdir/artest.a
Executing on host: /src/ginu/build/binutils/ar rcT tmpdir/artest2.a 
tmpdir/artest.a   (timeout = 300)
spawn /src/ginu/build/binutils/ar rcT tmpdir/artest2.a tmpdir/artest.a 
/src/ginu/build/binutils/nm-new --print-armap tmpdir/artest.a
Executing on host: /src/ginu/build/binutils/nm-new --print-armap 
tmpdir/artest.a   (timeout = 300)
spawn /src/ginu/build/binutils/nm-new --print-armap tmpdir/artest.a 
FAIL: ar thin archive with nested archive
Executing on host: /src/ginu/build/gas/as-new 
/src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/bintest.s  -o 
tmpdir/bintest.o(timeout = 300)
spawn /src/ginu/build/gas/as-new 
/src/ginu/binutils-2.19.51-1/binutils/testsuite/binut

[Mingw-w64-public] Msys and Dejagnu

2010-09-23 Thread Teemu Nätkinniemi 

Here's an example logs from building Binutils-2.19.51-1 (Msys)



Test Run By Teemu on Thu Sep 23 18:40:25 2010
Native configuration is i686-pc-msys

=== binutils tests ===

Schedule of variations:
unix

Running target unix
Using /share/dejagnu/baseboards/unix.exp as board description file for target.
Using /share/dejagnu/config/unix.exp as generic interface file for target.
Using /src/ginu/binutils-2.19.51-1/binutils/testsuite/config/default.exp as 
tool-and-target-specific interface file.
Running /src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/ar.exp ...
/src/ginu/build/binutils/ar rc tmpdir/artest.a 
tmpdir/abcdefghijklmnopqrstuvwxyz1 tmpdir/abcdefghijklmnopqrstuvwxyz2
Executing on host: /src/ginu/build/binutils/ar rc tmpdir/artest.a 
tmpdir/abcdefghijklmnopqrstuvwxyz1 tmpdir/abcdefghijklmnopqrstuvwxyz2   
(timeout = 300)
/src/ginu/build/binutils/ar rc tmpdir/artest.a 
tmpdir/abcdefghijklmnopqrstuvwxyz1 tmpdir/abcdefghijklmnopqrstuvwxyz2
Executing on host: /src/ginu/build/binutils/ar rc tmpdir/artest.a 
tmpdir/abcdefghijklmnopqrstuvwxyz1 tmpdir/abcdefghijklmnopqrstuvwxyz2   
(timeout = 300)
/src/ginu/build/binutils/ar t tmpdir/artest.a
Executing on host: /src/ginu/build/binutils/ar t tmpdir/artest.a   (timeout = 
300)
FAIL: ar long file names
Executing on host: /src/ginu/build/gas/as-new 
/src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/bintest.s  -o 
tmpdir/bintest.o(timeout = 300)
/src/ginu/build/binutils/ar rc tmpdir/artest.a tmpdir/bintest.o
Executing on host: /src/ginu/build/binutils/ar rc tmpdir/artest.a 
tmpdir/bintest.o   (timeout = 300)
/src/ginu/build/binutils/nm-new --print-armap tmpdir/artest.a
Executing on host: /src/ginu/build/binutils/nm-new --print-armap 
tmpdir/artest.a   (timeout = 300)
FAIL: ar symbol table
Executing on host: /src/ginu/build/gas/as-new 
/src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/bintest.s  -o 
tmpdir/bintest.o(timeout = 300)
/src/ginu/build/binutils/ar rcT tmpdir/artest.a tmpdir/bintest.o
Executing on host: /src/ginu/build/binutils/ar rcT tmpdir/artest.a 
tmpdir/bintest.o   (timeout = 300)
/src/ginu/build/binutils/nm-new --print-armap tmpdir/artest.a
Executing on host: /src/ginu/build/binutils/nm-new --print-armap 
tmpdir/artest.a   (timeout = 300)
FAIL: ar thin archive
Executing on host: /src/ginu/build/gas/as-new 
/src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/bintest.s  -o 
tmpdir/bintest.o(timeout = 300)
/src/ginu/build/binutils/ar rc tmpdir/artest.a tmpdir/bintest.o
Executing on host: /src/ginu/build/binutils/ar rc tmpdir/artest.a 
tmpdir/bintest.o   (timeout = 300)
/src/ginu/build/binutils/ar rcT tmpdir/artest2.a tmpdir/artest.a
Executing on host: /src/ginu/build/binutils/ar rcT tmpdir/artest2.a 
tmpdir/artest.a   (timeout = 300)
/src/ginu/build/binutils/nm-new --print-armap tmpdir/artest.a
Executing on host: /src/ginu/build/binutils/nm-new --print-armap 
tmpdir/artest.a   (timeout = 300)
FAIL: ar thin archive with nested archive
Executing on host: /src/ginu/build/gas/as-new 
/src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/bintest.s  -o 
tmpdir/bintest.o(timeout = 300)
/src/ginu/build/binutils/ar -r -c tmpdir/artest.a tmpdir/bintest.o
Executing on host: /src/ginu/build/binutils/ar -r -c tmpdir/artest.a 
tmpdir/bintest.o   (timeout = 300)
PASS: ar argument parsing
Executing on host: /src/ginu/build/gas/as-new 
/src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/bintest.s  -o 
tmpdir/bintest.o(timeout = 300)
/src/ginu/build/binutils/ar rcD tmpdir/artest.a tmpdir/bintest.o
Executing on host: /src/ginu/build/binutils/ar rcD tmpdir/artest.a 
tmpdir/bintest.o   (timeout = 300)
/src/ginu/build/binutils/ar tv tmpdir/artest.a
Executing on host: /src/ginu/build/binutils/ar tv tmpdir/artest.a   (timeout = 
300)
FAIL: ar deterministic archive
testcase /src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/ar.exp 
completed in 4 seconds
Running 
/src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/arm/objdump.exp ...
testcase 
/src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/arm/objdump.exp 
completed in 0 seconds
Running 
/src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/dlltool.exp ...
PASS: dlltool (fastcall export)
PASS: dlltool -p (execution)
/src/ginu/build/binutils/nm-new tmpdir/libalias.a
Executing on host: /src/ginu/build/binutils/nm-new tmpdir/libalias.a   (timeout 
= 300)
FAIL: dlltool -p (symbol names)
/src/ginu/build/binutils/objdump -s -j .idata$6 tmpdir/libalias.a
Executing on host: /src/ginu/build/binutils/objdump -s -j .idata\$6 
tmpdir/libalias.a   (timeout = 300)
FAIL: dlltool -p (import name)
testcase 
/src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/dlltool.exp 
completed in 1 seconds
Running 
/src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/hppa/objdump.exp 
...
testcase 
/src/ginu/binutils-2.19.51-1/binutils/testsuite/binutils-all/hppa/objdump.exp 
completed in 0 seconds
Run

Re: [Mingw-w64-public] rubenvb Personal Build

2010-09-23 Thread Teemu Nätkinniemi 
>> Here's Dejagnu + Expect + Tcl/Tk for Msys. Binaries only as the author
>> never released the sources. I haven't tested it for Mingw targets.
>>
>> http://www.mediafire.com/?gp8xkvej6b68ch8
>
> Built against what version of msys?
>

Most likely 1.0.11. Then again it just runs a script so it might
actually work. I'll try it later and try porting Cygwin's Tcl/Tk etc. to 
recent Msys as well.


--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-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] rubenvb Personal Build

2010-09-23 Thread Teemu Nätkinniemi 
 Can you run the testsuite? (Make -k check)


>>> I cannot, because MSYS doesn't have the necessary tools. It
>>> apparently only works on Cygwin, which don't have...
>>>
>>
>> What is missing?
>>
>> Earnie
>>
>
> Hi,
>
> gnu expect and runtest. There might be more, but I have not run the tests.

Here's Dejagnu + Expect + Tcl/Tk for Msys. Binaries only as the author 
never released the sources. I haven't tested it for Mingw targets.

http://www.mediafire.com/?gp8xkvej6b68ch8

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC problem with *.la files in /lib64

2010-09-18 Thread Teemu Nätkinniemi 

> I have built a toolchain using attached "script", and while using my
> in-progress fancy build script, I noticed that while compiling ppl, the
> *.la files in lib64 contained the following:
>
> # Directory that this library needs to be installed in:
> libdir='/home/ruben/mingw64/build/mingw64/lib/../lib64'
>
>
> Where sezero's builds contain:
>
> # Directory that this library needs to be installed in:
> libdir='/mingw64/lib/../lib64'
>
>
> and adjusting this corrects the build issue with ppl.
>
> The question is... why is that entry filled in incorrectly? You can see
> in the build script I use --with-prefix and --with-sysroot for gcc and
> binutils. What went wrong?

My two cents: sezero uses --prefix=/mingw64

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC stage1 lto broken?

2010-09-14 Thread Teemu Nätkinniemi 
I am currently stopped by:
Creating library file: ./shlib/libgcc_s.a.tmp
lto1.exe: error: bad value (core2) for -mtls-dialect= switch

lto-wrapper: M:\Development\msys\home\Ruben\mingw64\build\gcc\gcc\xgcc.exe 
returned 1 exit status
collect2: lto-wrapper returned 1 exit status

How about specifying tls-dialect manually? 


  --
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] libusb-win32 64bit device driver building with MinGW-w64

2010-09-10 Thread Teemu Nätkinniemi 

> libusb_driver.o:libusb_driver.c:(.text+0x6a9): undefined
> reference to `_Interloc
> kedIncrement'
> libusb_driver.o:libusb_driver.c:(.text+0x6d4): undefined
> reference to `_Interloc
> kedDecrement'
> libusb_driver.o:libusb_driver.c:(.text+0x70d): undefined
> reference to `_Interloc
> kedDecrement'
> transfer.o:transfer.c:(.text+0x149): undefined reference to
> `_InterlockedIncreme
> nt'
> transfer.o:transfer.c:(.text+0x19a): undefined reference to
> `_InterlockedDecreme
> nt'
> transfer.o:transfer.c:(.text+0x1cd): undefined reference to
> `_InterlockedDecreme
> nt'
> transfer.o:transfer.c:(.text+0x324): undefined reference to
> `_InterlockedDecreme
> nt'
> transfer.o:transfer.c:(.text+0x457): undefined reference to
> `_InterlockedExchang
> ePointer'
> transfer.o:transfer.c:(.text+0x4ed): undefined reference to
> `_InterlockedExchang
> ePointer'
> transfer.o:transfer.c:(.text+0x66d): undefined reference to
> `_InterlockedIncreme
> nt'
> transfer.o:transfer.c:(.text+0xe3f): undefined reference to
> `_InterlockedExchang
> ePointer'
> transfer.o:transfer.c:(.text+0xf76): undefined reference to
> `_InterlockedIncreme
> nt'
> collect2: ld returned 1 exit status
> make: *** [libusb0.sys] Error 1

On 64-bit Windows those should be InterlockedIncrement64 and 
InterlockedDecrement64.



  

--
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public