From: Georgi P. <gog...@gm...> - 2010-11-29 14:21:22
|
Hi, I've searched all mingw mailing lists and I didn't find the same problem. I'm trying to compile the latest SVN tree of MPlayer under MinGW/MSYS/Windows 7. The tree compiles, but the linking takes forever (I left it for hours when it should take 4-5 seconds) and never finishes. This happens *only* on Windows 7. The same tree links for 5 seconds under Windows XP in VMware on the same machine. Fresh install of Windows 7 in VMware (to rule out interfering programs on my installation) exhibits the same problem! How to reproduce? Pretty easy. 1) Install the latest MSYS+MinGW 2) Download the latest MPlayer SVN tree: svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer 3) ./configure --yasm='' 4) make This *has* to be done under Windows 7. XP is fine. I've installed MSYS/MinGW from mingw-get-inst-20101030.exe. In my case I used the 20101030 snapshot during the installation, but using latest packages doesn't make any difference. The most striking thing - I had an old MSYS/MinGW environment from 1 year ago with GCC 3.4.5. The same thing happens! I've explained the problem in great, great detail in this thread: http://thread.gmane.org/gmane.comp.video.mplayer.devel/58257 I won't repeat the same information here, as you can see every possible details and issues from the short thread above. I started to analyze it and made some progress, which might be of help to you. After 4 days trying, I think that fixing this bug is beyond my abilities, as you'll see that I've tried everything I could think of without touching the actual code. As I'm starting development of a very important MPlayer feature and compiling the tree under Windows 7 is of vital importance. I'll be glad if we can work together on fixing this frustrating issue! Greetings, Georgi $ gcc -v Using built-in specs. COLLECT_GCC=D:\Programs\mingw\bin\gcc.exe COLLECT_LTO_WRAPPER=d:/programs/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.5.0/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 --enable-version-specific-runtime-libs --disable-werror --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.5.0 (GCC) $ ld -v GNU ld (GNU Binutils) 2.20.51.20100613 $ uname -a MINGW32_NT-6.1 GOGO-PC 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 Msys |
From: PcX <xun...@gm...> - 2010-11-29 14:57:01
|
May you show your ld errors? Did you try a simple program compiling and linking on Win7? 于 2010/11/29 22:21, Georgi Petrov 写道: > Hi, > > I've searched all mingw mailing lists and I didn't find the same > problem. I'm trying to compile the latest SVN tree of MPlayer under > MinGW/MSYS/Windows 7. The tree compiles, but the linking takes forever > (I left it for hours when it should take 4-5 seconds) and never > finishes. This happens *only* on Windows 7. The same tree links for 5 > seconds under Windows XP in VMware on the same machine. Fresh install > of Windows 7 in VMware (to rule out interfering programs on my > installation) exhibits the same problem! > > How to reproduce? Pretty easy. > 1) Install the latest MSYS+MinGW > 2) Download the latest MPlayer SVN tree: svn checkout > svn://svn.mplayerhq.hu/mplayer/trunk mplayer > 3) ./configure --yasm='' > 4) make > > This *has* to be done under Windows 7. XP is fine. > > I've installed MSYS/MinGW from mingw-get-inst-20101030.exe. In my case > I used the 20101030 snapshot during the installation, but using latest > packages doesn't make any difference. The most striking thing - I had > an old MSYS/MinGW environment from 1 year ago with GCC 3.4.5. The same > thing happens! > > I've explained the problem in great, great detail in this thread: > http://thread.gmane.org/gmane.comp.video.mplayer.devel/58257 > > I won't repeat the same information here, as you can see every > possible details and issues from the short thread above. I started to > analyze it and made some progress, which might be of help to you. > > After 4 days trying, I think that fixing this bug is beyond my > abilities, as you'll see that I've tried everything I could think of > without touching the actual code. As I'm starting development of a > very important MPlayer feature and compiling the tree under Windows 7 > is of vital importance. > > I'll be glad if we can work together on fixing this frustrating issue! > > Greetings, > Georgi > > $ gcc -v > Using built-in specs. > COLLECT_GCC=D:\Programs\mingw\bin\gcc.exe > COLLECT_LTO_WRAPPER=d:/programs/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe > Target: mingw32 > Configured with: ../gcc-4.5.0/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 > --enable-version-specific-runtime-libs --disable-werror > --build=mingw32 --prefix=/mingw > Thread model: win32 > gcc version 4.5.0 (GCC) > > $ ld -v > GNU ld (GNU Binutils) 2.20.51.20100613 > > $ uname -a > MINGW32_NT-6.1 GOGO-PC 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 Msys > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App& Earn a Chance To Win $500! > Tap into the largest installed PC base& get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe -- Regards PcX |
From: Georgi P. <gog...@gm...> - 2010-11-29 15:43:44
|
On Mon, Nov 29, 2010 at 4:56 PM, PcX <xun...@gm...> wrote: > May you show your ld errors? > Did you try a simple program compiling and linking on Win7? > Compiling a simple program works. When MPlayer is being linked, there are no errors from ld.exe. It just sits and does nothing. If you are referring to the linking errors I talk about in the MPlayer mailing list, they are because I've removed several object files. The bottom line is that when too many object files are given in the final linking statement, the bug is triggered. If I start removing object files, at one point ld.exe exists with error about unresolved symbols, which is quite logical. As such, I don't think that providing any output will be meaningful. |
From: Peter R. <p.r...@sh...> - 2010-11-29 15:58:27
|
Just a thought: Could you isolate which object file(s) are causing problems by building groups of .o files into (static) libraries? P. On 29/11/10 15:43, Georgi Petrov wrote: > On Mon, Nov 29, 2010 at 4:56 PM, PcX<xun...@gm...> wrote: >> May you show your ld errors? >> Did you try a simple program compiling and linking on Win7? >> > Compiling a simple program works. > > When MPlayer is being linked, there are no errors from ld.exe. It just > sits and does nothing. If you are referring to the linking errors I > talk about in the MPlayer mailing list, they are because I've removed > several object files. > > The bottom line is that when too many object files are given in the > final linking statement, the bug is triggered. If I start removing > object files, at one point ld.exe exists with error about unresolved > symbols, which is quite logical. > > As such, I don't think that providing any output will be meaningful. > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App& Earn a Chance To Win $500! > Tap into the largest installed PC base& get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe |
From: Georgi P. <gog...@gm...> - 2010-11-29 20:24:31
|
On Mon, Nov 29, 2010 at 5:58 PM, Peter Rockett <p.r...@sh...> wrote: > Just a thought: Could you isolate which object file(s) are causing > problems by building groups of .o files into (static) libraries? > That's my point from MPlayer's thread - there are no particular object files, which cause the problem. The problem is caused because too much code must be compiled into the final binary (too many object files must be linked together). In other words - if I remove the 2 largest static libraries, ld.exe doesn't hang anymore, but exits with errors as expected. If I start cutting object code size from smaller object files, I should remove many of them to make ld.exe exit with an error message and don't hang anymore. In other words - I can't really isolate the problem, because the problem is size-based. If you want, I could make an archive with all object files and put it on my FTP server together with a simple runme.sh, which tries to link them into the final binary. This way the problem will be reproducible by everybody, who downloads the archive and tries to link the final .exe. Do you think this will help? |
From: Earnie <ea...@us...> - 2010-11-30 13:16:50
|
Georgi Petrov wrote: > On Mon, Nov 29, 2010 at 5:58 PM, Peter Rockett > <p.r...@sh...> wrote: >> Just a thought: Could you isolate which object file(s) are causing >> problems by building groups of .o files into (static) libraries? >> > > That's my point from MPlayer's thread - there are no particular object > files, which cause the problem. The problem is caused because too much > code must be compiled into the final binary (too many object files > must be linked together). > Peter is trying to tell you to use the ar command to build a library file of the "too many object files must be linked together" and then use that file to link with. > In other words - if I remove the 2 largest static libraries, ld.exe > doesn't hang anymore, but exits with errors as expected. If I start > cutting object code size from smaller object files, I should remove > many of them to make ld.exe exit with an error message and don't hang > anymore. > Yea, well, it doesn't get to the point of building the binary. > In other words - I can't really isolate the problem, because the > problem is size-based. > If the problem is the output of ld and not the input then the above solution won't help either. You'll then need to find a way to reduce the object files sizes such as removing the debugging information. -- Earnie -- http://www.for-my-kids.com |
From: Georgi P. <gog...@gm...> - 2010-11-30 13:31:15
|
> Peter is trying to tell you to use the ar command to build a library > file of the "too many object files must be linked together" and then use > that file to link with. Yes, I understood. Tomorrow I'll try and will report the result. However, common sense tells me that the problem won't go away, because the same amount of code will have to be linked together anyway. > If the problem is the output of ld and not the input then the above > solution won't help either. That's what I'm thinking, but I will try and report. > You'll then need to find a way to reduce > the object files sizes such as removing the debugging information. No. We will have to find the bug and fix it. The point of this thread is ultimately fixing the issue and not trying to work around it. I've already tried removing debugging information, compiling only the essential functionality and anything I could think of. It failed. Now I'm trying to use another linker (Open Watcom). |
From: Georgi P. <gog...@gm...> - 2010-12-01 23:01:04
|
Ok, I'm giving up. 1 week was enough. More than 30 hours with this issue and not even a single percent success. A friend of mine with Windows 7 x64 compiles and links the tree just fine. I thought that Windows 7 x64 may be the final answer. I installed it in VMware and linking failed. Next - my friend tried my VMware image with 32 bit Windows 7 and the compilation failed on his machine (having in mind that on his native Windows 7 x64 it succeeded)... We both don't have any explanation. This is insane!!! I tried to aggregate all object files into a static library and to link it along with other static libraries... You can guess the result. After another 4 hours spent with Open Watcom's linker, which complained about a ton of things and finally after reading the by-alien-written user's manual, gave me an .exe file, which crashes on startup... That's enough. ld.exe from the U++ project, which was a drop-in replacement, supposed to fix a similar problem from 2006 produced another mplayer.exe, which crashes. Trying to compile older ld from older binutils under MinGW proved another bloody mistake. I don't have enough desire for experimenting with IBM's linker, given the pain I went through with the Witcom's one. Since almost nobody seems to be interested in compiling MPlayer on Windows 7, I'm a minority without any chance of finding a similar soul. I'm starting DxVA development from tomorrow by linking on VMware + XP, running in the background just for ld.exe :( |
From: Bidski <bi...@bi...> - 2010-12-02 00:02:47
|
Hello Georgi, I just followed your instructions on how to build mplayer 1) Install the latest MSYS+MinGW (already had it installed. Im using TDM64-GCC-4.5.1 and the latest version of MSYS that is on the mingw-w64 sourceforge website) 2) Download the latest MPlayer SVN tree: svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer (done, but added a svn update afterwards just to be doubly sure) 3) ./configure --yasm='' (done, no noticeable errors) 4) make (done, no noticeable errors) It took me maybe all of 20 minutes to complete the whole thing. Im wondering, on your failed builds what is the average size of your object files? I ran into a similar (similar in the respect that ld "hanged") problem nearly a year ago with GCC-4.5.0 when I was trying to build wxWidgets and ld failed because it exhausted it supply of memory (2GB+), I solved this problem by going to the TDM builds of GCC. My build of mplayer has 1,049 object files totalling just over 11MB, is yours the same? Is the problem I just described similar in any way to the one you are experiencing? Im running on Windows 7 64 bit Regards Bidski |
From: J D. <d3...@gm...> - 2010-12-02 16:59:53
|
watcom demands that you compile with the correct build target type flags - like -bd or -bw otherwise it doesn't work right at all... On Wed, Dec 1, 2010 at 3:00 PM, Georgi Petrov <gog...@gm...> wrote: > Ok, I'm giving up. 1 week was enough. More than 30 hours with this > issue and not even a single percent success. > > A friend of mine with Windows 7 x64 compiles and links the tree just > fine. I thought that Windows 7 x64 may be the final answer. I > installed it in VMware and linking failed. Next - my friend tried my > VMware image with 32 bit Windows 7 and the compilation failed on his > machine (having in mind that on his native Windows 7 x64 it > succeeded)... We both don't have any explanation. This is insane!!! > > I tried to aggregate all object files into a static library and to > link it along with other static libraries... You can guess the result. > > After another 4 hours spent with Open Watcom's linker, which > complained about a ton of things and finally after reading the > by-alien-written user's manual, gave me an .exe file, which crashes on > startup... That's enough. > > ld.exe from the U++ project, which was a drop-in replacement, supposed > to fix a similar problem from 2006 produced another mplayer.exe, which > crashes. > > Trying to compile older ld from older binutils under MinGW proved > another bloody mistake. > > I don't have enough desire for experimenting with IBM's linker, given > the pain I went through with the Witcom's one. Since almost nobody > seems to be interested in compiling MPlayer on Windows 7, I'm a > minority without any chance of finding a similar soul. > > I'm starting DxVA development from tomorrow by linking on VMware + XP, > running in the background just for ld.exe :( > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > |
From: Georgi P. <gog...@gm...> - 2010-12-02 12:54:48
|
On Thu, Dec 2, 2010 at 2:02 AM, Bidski <bi...@bi...> wrote: > Hello Georgi, > > I just followed your instructions on how to build mplayer > > 1) Install the latest MSYS+MinGW (already had it installed. Im using > TDM64-GCC-4.5.1 and the latest version of MSYS that is on the mingw-w64 > sourceforge website) > 2) Download the latest MPlayer SVN tree: svn checkout > svn://svn.mplayerhq.hu/mplayer/trunk mplayer (done, but added a svn update > afterwards just to be doubly sure) > 3) ./configure --yasm='' (done, no noticeable errors) > 4) make (done, no noticeable errors) Hello Bidski, Thank you for trying. As I have Windows 7 64 bit in VMware, I did the exact same thing as you: I used TDM64-GCC-4.5.1 and latest MSYS. ld.exe hangs. The strangest thing is that the issue dependent on some variable I can't rule out. The very same tree compiles on my friend's Windows 7 64 bit, but on my VMware Windows 7 64 bit it fails. On the other side both our machines hang trying to compile it inside VMware Windows 7 32 bit... > It took me maybe all of 20 minutes to complete the whole thing. Im > wondering, on your failed builds what is the average size of your object > files? .o files: 1146 files, 12.2MB .a files: 6 files, 7.33MB > I ran into a similar (similar in the respect that ld "hanged") > problem nearly a year ago with GCC-4.5.0 when I was trying to build > wxWidgets and ld failed because it exhausted it supply of memory (2GB+), I'm constantly reading mail list threads about people with similar problems, but the solutions and problems themselves are different. They mostly complain about bigger C++ projects. In my case ld.exe takes 20MB RAM and this is far away from any imaginable limit. > solved this problem by going to the TDM builds of GCC. In my case TDM builds don't help. Neither 32, nor 64 bit. BTW, why TDM64 builds feature 32 bit toolchain? I was hoping to see 64 bit gcc.exe, ld.exe and so on, but they are 32 bit... > My build of mplayer > has 1,049 object files totalling just over 11MB, is yours the same? 1146 files, but under mingw32 and 32 bit Windows 7. 12,2 MB. > Is the > problem I just described similar in any way to the one you are experiencing? No. In my case ld.exe's memory usage stays under 20MB. The strange thing is that in the VM it takes 99% CPU usage and on my native system it stays close to 0%. > > Im running on Windows 7 64 bit On my "native" Windows 7 32 bit all possible combinations fail. The same could be said about Windows 7 64 bit in VMware. In the other side XP in VMware linkes MPlayer just fine. Regards, Georgi |
From: Eran I. <era...@gm...> - 2010-12-02 13:08:15
|
Hi Georgi, I experienced similar issues when building wxWidgets using GCC4.5.X - eventually I ended up downgrading back to GCC4.4.1 and it seems to work out of the box for me. You might want to try GCC4.4.1 (there is one bundled with codelite here: http://sourceforge.net/projects/codelite/files/Releases/codelite-2.8/codelite-2.8.0.4537-mingw4.4.1.exe/download) On Thu, Dec 2, 2010 at 2:54 PM, Georgi Petrov <gog...@gm...> wrote: > On Thu, Dec 2, 2010 at 2:02 AM, Bidski <bi...@bi...> wrote: >> Hello Georgi, >> >> I just followed your instructions on how to build mplayer >> >> 1) Install the latest MSYS+MinGW (already had it installed. Im using >> TDM64-GCC-4.5.1 and the latest version of MSYS that is on the mingw-w64 >> sourceforge website) >> 2) Download the latest MPlayer SVN tree: svn checkout >> svn://svn.mplayerhq.hu/mplayer/trunk mplayer (done, but added a svn update >> afterwards just to be doubly sure) >> 3) ./configure --yasm='' (done, no noticeable errors) >> 4) make (done, no noticeable errors) > > Hello Bidski, > > Thank you for trying. As I have Windows 7 64 bit in VMware, I did the > exact same thing as you: I used TDM64-GCC-4.5.1 and latest MSYS. > > ld.exe hangs. > > The strangest thing is that the issue dependent on some variable I > can't rule out. The very same tree compiles on my friend's Windows 7 > 64 bit, but on my VMware Windows 7 64 bit it fails. > > On the other side both our machines hang trying to compile it inside > VMware Windows 7 32 bit... > >> It took me maybe all of 20 minutes to complete the whole thing. Im >> wondering, on your failed builds what is the average size of your object >> files? > > .o files: 1146 files, 12.2MB > .a files: 6 files, 7.33MB > >> I ran into a similar (similar in the respect that ld "hanged") >> problem nearly a year ago with GCC-4.5.0 when I was trying to build >> wxWidgets and ld failed because it exhausted it supply of memory (2GB+), > > I'm constantly reading mail list threads about people with similar > problems, but the solutions and problems themselves are different. > They mostly complain about bigger C++ projects. In my case ld.exe > takes 20MB RAM and this is far away from any imaginable limit. > >> solved this problem by going to the TDM builds of GCC. > > In my case TDM builds don't help. Neither 32, nor 64 bit. BTW, why > TDM64 builds feature 32 bit toolchain? I was hoping to see 64 bit > gcc.exe, ld.exe and so on, but they are 32 bit... > >> My build of mplayer >> has 1,049 object files totalling just over 11MB, is yours the same? > > 1146 files, but under mingw32 and 32 bit Windows 7. 12,2 MB. > > >> Is the >> problem I just described similar in any way to the one you are experiencing? > > No. In my case ld.exe's memory usage stays under 20MB. The strange > thing is that in the VM it takes 99% CPU usage and on my native system > it stays close to 0%. > >> >> Im running on Windows 7 64 bit > > On my "native" Windows 7 32 bit all possible combinations fail. The > same could be said about Windows 7 64 bit in VMware. In the other side > XP in VMware linkes MPlayer just fine. > > Regards, > Georgi > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > -- Eran Ifrah Cross platform, open source C++ IDE: http://www.codelite.org |
From: Georgi P. <gog...@gm...> - 2010-12-02 15:17:31
|
On Thu, Dec 2, 2010 at 3:07 PM, Eran Ifrah <era...@gm...> wrote: > Hi Georgi, > > I experienced similar issues when building wxWidgets using GCC4.5.X - > eventually I ended up downgrading back to GCC4.4.1 and it seems to > work out of the box for me. > > You might want to try GCC4.4.1 (there is one bundled with codelite > here: http://sourceforge.net/projects/codelite/files/Releases/codelite- Hi Eran, I tried, but ld.exe hangs again. I'm stunned. I've tried no less than 5-6 different builds of binutils + gcc and I can't find any one that leads to success here. The most striking thing is that it is clearly a function of the hardware configuration as well, because a friend of mine with a fairly similar computer compiles the tree under Windows 7 64 bit.... Interfering programs are rules out, because fresh Windows installations in VMware hang as well. Any ideas what else could be responsible for the problem? |
From: Geir M. <Gei...@hr...> - 2010-12-02 15:58:39
|
Hi, > Any ideas what else could be responsible for the problem? Sorry, no, but since it is ld.exe that hangs, should it not be possible to build a debug version of ld.exe from source, and see what really happens by using gdb ? Geir |
From: Earnie <ea...@us...> - 2010-12-03 12:34:44
|
Geir Meyer wrote: > Hi, > >> Any ideas what else could be responsible for the problem? > > Sorry, no, but since it is ld.exe that hangs, should it not be possible to build a debug version of ld.exe from source, > and see what really happens by using gdb ? > System memory issue? Run the CMOS memory diagnostics to find out. -- Earnie -- http://www.for-my-kids.com |
From: Georgi P. <gog...@gm...> - 2010-12-03 15:48:44
|
On Thu, Dec 2, 2010 at 5:58 PM, Geir Meyer <Gei...@hr...> wrote: > Hi, > >> Any ideas what else could be responsible for the problem? > > Sorry, no, but since it is ld.exe that hangs, should it not be possible to build a debug version of ld.exe from source, > and see what really happens by using gdb ? Hi, Yes, it is possible. As I have to start developing for my project, initially I will link in XP in VMware. After few days I will have some time and I will investigate this issue further. I'm willing to help, which means compiling ld.exe with debug information and tracing the difference in execution on my computer and the computer of my friend (where it linked just okay). I will need some help from you, since I don't really understand ld.exe's internals, but at least I will point the function or code chunk where the problems happens. On Thu, Dec 2, 2010 at 6:59 PM, J Decker <d3...@gm...> wrote: > watcom demands that you compile with the correct build target type > flags - like -bd or -bw otherwise it doesn't work right at all... > I spent so much time with this linker and I had so many issues, that I'm not willing to continue trying. However, thanks for pointing out that it can be used to link GCC generated code. I wasn't aware, because I never used anything else than ld. > > System memory issue? Run the CMOS memory diagnostics to find out. > Tonight I will leave memtest86+ to test my system memory, but this seems very, very unlikely. I don't remember having an OS crash for months and I don't restart the OS for weeks. If I had any memory problems, I would have noticed. However, I will surely run memtest86+. Also the same linking problem occurs on my friend's machine using my Windows 7 32 bit VMware image, so my hardware is ruled out. |
From: John B. <joh...@ho...> - 2010-12-03 18:35:07
|
On Fri, 3 Dec 2010 17:41:12 +0200, Georgi Petrov wrote: > > On Thu, Dec 2, 2010 at 5:58 PM, Geir Meyer wrote: >> Hi, >> >>> Any ideas what else could be responsible for the problem? >> >> Sorry, no, but since it is ld.exe that hangs, should it not be possible to build a debug version of ld.exe from source, >> and see what really happens by using gdb ? > > Hi, > > Yes, it is possible. As I have to start developing for my project, > initially I will link in XP in VMware. After few days I will have some > time and I will investigate this issue further. [snip] > > On Thu, Dec 2, 2010 at 6:59 PM, J Decker wrote: >> watcom demands that you compile with the correct build target type >> flags - like -bd or -bw otherwise it doesn't work right at all... >> > > I spent so much time with this linker and I had so many issues, that > I'm not willing to continue trying. However, thanks for pointing out > that it can be used to link GCC generated code. I wasn't aware, > because I never used anything else than ld. > >> >> System memory issue? Run the CMOS memory diagnostics to find out. >> > > Tonight I will leave memtest86+ to test my system memory, but this > seems very, very unlikely. I don't remember having an OS crash for > months and I don't restart the OS for weeks. If I had any memory > problems, I would have noticed. However, I will surely run memtest86+. > > Also the same linking problem occurs on my friend's machine using my > Windows 7 32 bit VMware image, so my hardware is ruled out. > Have you tried ProcMon? That woud be another way to find out what ldis doing when it hangs. I assume that you have already eliminated youranti-virus. Regards,Alias John Brown. |
From: Georgi P. <gog...@gm...> - 2010-12-04 08:51:53
|
> Have you tried ProcMon? That woud be another way to find out what ldis doing when it hangs. I assume that you have already eliminated youranti-virus. > Regards,Alias John Brown. My hardware is ruled out. memtest86+ showed no errors. I know about ProcMon and will used it additionally when I report what I've found. Yes, anti-virus was ruled out early in the test process so far. |
From: Greg C. <gch...@sb...> - 2010-12-04 16:38:05
|
On 2010-12-04 08:51Z, Georgi Petrov wrote: > > [...] Yes, anti-virus was ruled out early in the test process so far. Did you uninstall all "security" software completely, as opposed to just disabling it? Cygwin experience http://cygwin.com/faq/faq.using.html#faq.using.bloda indicates that disabling it may be insufficient. That page also lists other known offenders such as logitech's webcam software. |
From: Georgi P. <gog...@gm...> - 2010-12-04 20:06:46
|
> Did you uninstall all "security" software completely, as opposed > to just disabling it? Cygwin experience > http://cygwin.com/faq/faq.using.html#faq.using.bloda > indicates that disabling it may be insufficient. That page also > lists other known offenders such as logitech's webcam software. Thanks for this list. Yes, I uninstalled Microsoft Security Essentials and didn't just disable it. I know that a kernel module and/or some hooks may be still operational when the AV is only disabled. I don't have any software from the list installed on my system. Besides, a clean Windows 7 in VMware doesn't suffer from those things and linking still fails inside as well. I have a strange idea. Since VMware uses paravirtualization and the virtualized HW isn't 100% "emulated", I will setup a Bochs VM, which is supposed to create 100% genuine host-specifics-free environment. I will report the results tomorrow :) I'm doing this, because I need a clear distinction between a successful and failed linking. I have the XP vs 7 case, but I would like to have 7 vs 7 case with a failure and success. Any possible variables should be ruled out :) |
From: Georgi P. <gog...@gm...> - 2010-12-04 20:16:53
|
I didn't mean "paravirtualization" in its real sense, but you get the point... |
From: Georgi P. <gog...@gm...> - 2010-12-06 18:03:44
|
Problem "solved"!!! Please read the complete solution without VMware or anything like that. You will be surprised!!! When every attempt so far failed, I did set up a XP installation from inside VMware, which was going to compile/link MPlayer from a shared folder from the host (Windows 7). The host (Win 7) should provide a shared tree and the guest (XP) should access the tree and compile/link mplayer.exe. Let me remind you that ld.exe doesn't hang in XP. You can't imagine my surprise when linking hanged! Actually my Windows 7 "side" hanged and it was responsible only for providing MPlayer's tree as a directory share!!! Now the whole VMware process couldn't be killed, just like when running native ld.exe... I was in shock, because it didn't make sense. Using Sysinternals Process Monitor, I was able to isolate the very same problem when: 1) ld.exe in Windows 7 (in VMware or on my machine) hangs. 2) Windows 7 on my machine hangs while only providing a file share to the XP, trying to link from inside VMware. ld.exe doesn't hang. VMware's process (with XP and ld.exe inside) didn't hang. The NT kernel did!!! This is the stack from hanged ld.exe (and supposedly VMware's) process: ntdll.dll!KiFastSystemCallRet kernel32.dll!WriteFile+0x4e msvcrt.dll!fprintf+0x235 msvcrt.dll!write+0x73 msvcrt.dll!CIcos+0x248 msvcrt.dll!fscanf_s_l+0x68 msvcrt.dll!fseeki64+0x2a msvcrt.dll!fsetpos+0x3f ld.exe+0x96e09 ld.exe+0x34c1b ld.exe+0x400d1 ld.exe+0x2560a ld.exe+0x4f2ac ld.exe+0x50083 ld.exe+0x14543 ld.exe+0x134f1 ld.exe+0x10db ld.exe+0x1178 kernel32.dll!BaseThreadInitThunk+0x12 ntdll.dll!RtlInitializeExceptionChain+0x63 ntdll.dll!RtlInitializeExceptionChain+0x36 The "hanged call" is "KiFastSystemCallRet" in ntdll.dll! This explains why I can't kill ld.exe or VMware's process (with "hanged" ld.exe inside). They are waiting for the NT executive to finish a system call! This was jaw-dropping. Obviously XP's function call returned, but Windows 7's one hanged. In theory this means that I can host the tree in XP inside VMware or even Linux inside VMware and share it to my machine's Windows 7. Fortunately, a strange thought went through my head - what about the file system? Would the same bug in ntdll.dll happen on a FAT32 partition? So, I created one, copied the tree inside and.. guess what... It didn't hang. mplayer.exe was built. Yes, the tree compiles and links just fine on my Windows 7 (no VMware) on a FAT32 partition... This doesn't solve the problem itself, but "works for me". I guess that ld.exe's file write logic somehow triggers a bug in ntdll.dll under certain circumstances. This is only a speculation from my uneducated point of view. See the last few calls: ntdll.dll!KiFastSystemCallRet kernel32.dll!WriteFile+0x4e msvcrt.dll!fprintf+0x235 msvcrt.dll!write+0x73 MSVCRT's write function uses fprintf to write to a stream (file stream obviously), then we have kernel32.dll's WriteFile and finally ntdll.dll's hanging KiFastSystemCallRet. This is insane, but a proven fact. My problem is solved. Should I contact Microsoft and file something like a bug report? |
From: Earnie <ea...@us...> - 2010-12-07 13:18:46
|
Georgi Petrov wrote: > Problem "solved"!!! > I'm glad you worked around the Microsoft bug. Be sure to let their support know of the bug you found. > Please read the complete solution without VMware or anything like > that. You will be surprised!!! > I would like you to write this up on the http://www.mingw.org/wiki so that we have it for others to review. If you do not have permissions, give me your www.mingw.org login user name and I can resolve that. Thanks, -- Earnie -- http://www.for-my-kids.com |
From: Georgi P. <gog...@gm...> - 2010-12-15 13:06:13
|
On Tue, Dec 7, 2010 at 3:18 PM, Earnie <ea...@us...> wrote: > Georgi Petrov wrote: >> Problem "solved"!!! >> > > I'm glad you worked around the Microsoft bug. Be sure to let their > support know of the bug you found. Thanks, I'm working with an MS developer on the issue. > I would like you to write this up on the http://www.mingw.org/wiki so > that we have it for others to review. If you do not have permissions, > give me your www.mingw.org login user name and I can resolve that. Great, I'll try in a few days! |
From: Georgi P. <gog...@gm...> - 2011-01-25 13:44:26
|
Hi, > I would like you to write this up on the http://www.mingw.org/wiki so > that we have it for others to review. If you do not have permissions, > give me your www.mingw.org login user name and I can resolve that. The Microsoft developer still haven't answered me. However, I'm willing to write this Wiki article. I went to http://www.mingw.org/wiki, but where (in which section) should I put the article? Also, my profile is not authorized for creating new articles. Could you please set the permissions? The profile name is "gogothebee". |