ld -Bdynamic -o bin\Debug\Hello Wrld.exe crt2.o crtbegin.o -LC:\MinGW\lib\gcc\mingw32\3.4.2 -LC:\MinGW\lib -L obj\Debug\main.o -lstdc++ -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt crtend.o
ld: crt2.o: No such file: No such file or directory
Using mingw 3.4.2 and vista business. It started out with the usual menagerie of problems. Fixed those and then stuck at this little problem. After adding the -v to the linker I came up with this messy looking command line. According to http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_3.html#SEC3 (http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_3.html#SEC3) this looks about right. The 'missing' file is located in C:\MinGW\lib. I've tried every fix I could find and come up blank. The same problem occurred with wxDev-Cpp so I assume this is pretty much a mingw problem as others have mentioned. Is there any cure for this yet besides reinstalling windows? How do I force this !#$%@# linker to recognize the search directories? There seem to be some options under other settings -> advanced options for the linker that I'll toy with next, but barring something new I'm stumped.
PS The two additional files required are both in the CodeBlocks directory, so that's definitely not it.
Nevermind. I've found the answer(s).
1) My project MUST at least be located on the same drive as mingw. It may also need to be under the root directory like so: C:/projectname. If you're still having trouble with crt2.0, it's worth a shot.
2) Your project's name must be 'vistasucks'. If you'll look here:
Quoteld -Bdynamic -o bin\Debug\vistasucks.exe /mingw/lib/gcc/mingw32/3.4.2/crt2.o /mingw/lib/gcc/mingw32/3.4.2/crtbegin.o -LC:\MinGW\lib -LC:\MinGW\lib\gcc\mingw32\3.4.2 -L/mingw/lib/gcc/mingw32/3.4.2 -L/mingw/mingw32/lib -L/mingw/lib -L -L/mingw/lib obj\Debug\main.o -lstdc++ -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt /mingw/lib/gcc/mingw32/3.4.2/crtend.o
Process terminated with status 0 (0 minutes, 10 seconds)
0 errors, 0 warnings
As you can see, denigrating vista is the only way to appease mingw, which appears to have a serious dislike of living in close proximity to so much useless eye candy. Ming also wants as much root action as possible, having some serious megalomania issues. We now return you to your regularly scheduled compiler problems.
Quote
Hello Wrld.exe
Rule #1 for MINGW projects: DO *NOT*, I repeat, ABSOLUTELY DO *NOT* USE S P A C E S.
(I'm just clarifying what the above poster tried to say).
To be clear: I tried it without spaces on the D: (D is for D:ocuments) drive before moving to over to C: (C is for C:RAP) and it still didn't work until I put it in C:/vistasucks. But yes, spaces are a no no :)
Hi ironlizard,
we are using also mingw compilers. But the current version (3.4.x and 4.x) of compilers do not work under windows Vista, so we made a patch in gcc/gcc.c
#ifdef WIN32
2381 /* VISTA patch:
2382 in vista the access with X_OK = 1 no longer works
2383 as a woarkaround we use F_OK (file exists) and at the
2384 extension .exe if necessary
2385 */
2386 static int
2387 __win32_access_check(const char *name, int mode)
2388 {
2389 char *tmp_name;
2390 int len = strlen(name);
2391 const char *const file_suffix = ((mode & X_OK) != 0 ? HOST_EXECUTABLE_SUFFIX : "");
2392 int suffix_len = strlen(file_suffix);
2393
2394 if (mode == X_OK) {
2395 if (len > suffix_len && suffix_len && !strcmp(&name[len-suffix_len],file_suffix))
2396 return access(name,F_OK);
2397 else
2398 {
2399 tmp_name = alloca(len+suffix_len);
2400 strcpy (tmp_name,name);
2401 strcat (tmp_name, file_suffix);
2402 return access(tmp_name,F_OK);
2403 }
2404 }
2405 else
2406 return access(name,mode);
2407 }
2408 #endif
2409 static int static int
2410 access_check (const char *name, int mode) access_check (const char *name, int mode)
2411 { {
2412 if (mode == X_OK) if (mode == X_OK)
2413 { {
2414 struct stat st; struct stat st;
2415
2416 if (stat (name, &st) < 0 if (stat (name, &st) < 0
2417 || S_ISDIR (st.st_mode)) || S_ISDIR (st.st_mode))
2418 return -1; return -1;
2419 #ifdef WIN32
2420 return __win32_access_check(name, mode);
2421 #endif
2422 } }
2423
2424 return access (name, mode); return access (name, mode);
2425 }
}
and in libiberty/make-relative-prefix.c
/* on WIN32 we test only file exists including the executable suffix */
86 /* workaround for VISTA */
87 # undef X_OK
88 # define X_OK 0
89 #else #else
90 # define HOST_EXECUTABLE_SUFFIX ""
91 # define PATH_SEPARATOR ':' # define PATH_SEPARATOR ':'
92 #endif #endif
and replace the line
nstore = (char *) alloca (prefixlen + strlen (progname) + 1);
with
nstore = (char *) alloca (prefixlen + strlen (progname) + 1 + strlen(HOST_EXECUTABLE_SUFFIX));
in make-relative.c.
We made this patch and now the mingw based compilers work on vista. As we are still testing, we did not public this patch.
Bye
Very cool, thanks mariocup.
I may try that after/if I get wxwidgets to compile, getting the gcc cc1 error now :!:
edit: Fixed
Quote from: 20-40 on July 18, 2007, 01:24:34 PM
LOL ironl, you are breeze of freshness here.
I'm merely using my considerable wit and charm to disguise the fact that I'm
utterly clueless, but thanks.
I have discovered another problem whilst compiling the wxwidgets. (This is beginning to look like a pattern, no?)
Quoteld: cannot find -lwxmsw28ud
It would seem a simple matter to locate wxmsw28ud.a and tell this infuriating linker where to find it. Not so, there is no such file. There is, however a:
Quotewxmsw28.a
Does this have anything to do with unicode support (I distinctly remember something about compiling with unicode on, but the wxwidgets instructions didn't mention it) ? Am I barking up the wrong directory tree?
It is a unicode debug file. OK, now I'm lost. Where would I find this wxmsw28ud?
Quote from: ironlizard on July 18, 2007, 05:49:38 PM
It is a unicode debug file. OK, now I'm lost. Where would I find this wxmsw28ud?
You have to compile wxWidgets with those settings.
e.g.
mingw32-make -f makefile.gcc BUILD=debug UNICODE=1
OK, can do. I originally compiled using the instructions found at http://www.wxwidgets.org/wiki/index.php/CodeBlocks_Setup_Guide (http://www.wxwidgets.org/wiki/index.php/CodeBlocks_Setup_Guide).
So after moving the first set of libraries, a second compilation for UC will yield the rest of the required files. OK, thank you Raph. I have a feeling this isn't the end, but we've made great progress. Back in ~35 minutes.
Ok I tried that. Well, actually, I tried: mingw32-make.exe -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=debug UNICODE=1
Is this bad? There is still no such file as libwxmsw28ud, BUT there are other, similar files in C:\wxWidgets-2.8.4\lib\gcc_lib. I also hadn't noticed they were all prefixed with 'lib' (these files, they are democrats?). They all have _something at the end (i.e.: _richtext, _xrc or whatever.). I must be missing something obvious here.
Ok, I created another project with a 'release' build configuration, since that's how I'd compiled it to begin with and it stopped complaining about the missing library. So far so good. Attempting to compile this mostly empty project, however, is no less exasperating.
Here are the latest results:
obj\Release\OnemoretimeMain.o:OnemoretimeMain.cpp:(.text+0x40): undefined reference to `_imp___ZN12wxStringBase4nposE'
There are 50 (compiler max apparently) errors that are quite similar. No complaints of a missing file this time, but there obviously is a missing file somewhere.
Apologies for the barrage of questions. Is this experience typical? Or am I somehow special?
Once again, nevermind. The problem is: the wizard and builds don't agree. So I'll be busy building every possible variation of wxwidgets just to be sure. Let's just say it's a variation on 'nuke it from orbit'. Well, my PC will be busy with that. *I* am going to find something a bit more fun to occupy my time. Thanks again, everyone.
Thanks, 20-40. I've saved the batch file for future use, it'll certainly prevent me from having to mess with the path again.
I have now built pretty much every configuration of wxwidgets anyone is likely to ever use. Great, no more missing files no matter what I pick in the wizard.
It's still broken. Same undefined reference problems:
:c:/vistasucks/lastdamntime/lastdamntimeMain.cpp:71: undefined reference to `_imp__wxDefaultSize'
and lots of them.
Perhaps after I've decoded this: http://www.wxwidgets.org/wiki/index.php/Installing_WxWin_MinGW (http://www.wxwidgets.org/wiki/index.php/Installing_WxWin_MinGW) I will know more.
Edit: I take it back, these undefined errors are different.
OK, I'll have to take your word for it. It's building again.
(btw, must add cc1's path to the batch file sometime C:\MinGW\libexec\gcc\mingw32\3.4.2, in my case)
It's no good, even after integrating. I'm going to try this wxpack thing next.
I installed wxpack. Same problem.
Turns out all of this $#%# was completely unnecessary.
The fix is at http://wiki.codeblocks.org/index.php?title=Compiling_wxWidgets_2.4.2_to_develop_Code::Blocks_(MSW) (http://wiki.codeblocks.org/index.php?title=Compiling_wxWidgets_2.4.2_to_develop_Code::Blocks_(MSW))
(bottom of the page)
As follows:
Quoteundefined reference to `_imp__wxTheApp' (& others)
If you encounter this one, try changing your linker options.
1. MENU: Settings->configure plugins->compiler->other->advanced options (for me it was Settings->Compiler->Other->Advance)
2. Choose: "Link object files to executable".
3. It should be: $linker -o $exe_output $libdirs $link_objects $libs $link_options
Worked for me. Original credits to rickg22 (see this thread) - rykon
And so ends this three day saga. The story of a quest to avoid using managed code with dependencies on just in time compiling frameworks is over. Now I can begin the task of ... *$%# it's been so long I forgot what the hell I needed this for. Well, at any rate, I can now rest assured that whatever task I had set myself to, before this untimely failure set off my attention deficit difficulties, can now be accomplished with relative ease. Or something.
Wait, what? Why? Everything is working now. Will editing mingw.bat remind me of the incredibly important task I've forgotten? Will it take out the trash I've completely forgotten until this very moment after being edited? I DON'T UNDERSTAND!
UNDER WINDOWS VISTA YOU MUST HAVE CRT2.O, CRTBEGIN.O AND CRTEND.O
LOCATED ON THE BASE PROJECT FOLDER
IF YOU MISS TO DO THAT
LD WILL NOT LINK! :shock:
very truly yours
THE NET CENTINELL
GIVING THE LINKER A PROPER SET OF ARGUMENTS SEEMED TO WORK WITHOUT THE NEED FOR STUFFING FILES IN THE PROJECT DIRECTORY THAT DON'T BELONG THERE BUT THANKS FOR THE REPLY. I THINK YOUR CAPS LOCK IS STUCK, BY THE WAY.
I'd like to note that this same problem still exists (C:BB mingw configuration sucks a lot).
After noticing the -v comment in the title, here's what I saw mingw-g++.exe invoke:
Quoteld -Bdynamic -o bin\Debug\test.exe crt2.o crtbegin.o -LC:\Unix\bin\MinGW\lib obj\Debug\main.o -lstdc++ -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt crtend.o
ld: crt2.o: No such file: No such file or directory
If you think about it, the error is clear. These are simple .o files,
not libraries - therefore using -L won't help here.
I'd also like to point out that if I run the same initial command from the commandline, I get
Quoteld -Bdynamic -o C:\test\bin\Debug\test.exe C:/Unix/bin/MinGW/lib/crt2.o C:/Unix/bin/MinGW/lib/gcc/mingw32/3.4.5/crtbegin.o -LC:\Unix\bin\MinGW\lib -LC:/Unix/bin/MinGW/lib/gcc/mingw32/3.4.5 -LC:/Unix/bin/MinGW/lib/gcc -LC:/Unix/bin/MinGW/mingw32/lib -LC:/Unix/bin/MinGW/lib C:\test\obj\Debug\main.o -lstdc++ -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt C:/Unix/bin/MinGW/lib/gcc/mingw32/3.4.5/crtend.o
and it links just fine. So who exactly is screwing up here?
It's CB. As you can see in the results you got (I noticed this too when recompiling everything), CB doesn't expand the PATH variable for the object by default because the linker's arguments are incorrect. In the wrong order, or something, I forget.They might work under another OS, but not this one. Did you try changing the command line configuration in CB to this: $linker -o $exe_output $libdirs $link_objects $libs $link_options
It works. No seriously. Just do it, you'll thank me. Alternatively, you could go through that entire process that I did in the course of this thread. It's up to you man. Save yourself and run now.
Quote from: ironlizard on September 03, 2007, 08:20:28 PM
It's CB. As you can see in the results you got (I noticed this too when recompiling everything), CB doesn't expand the PATH variable for the object by default because the linker's arguments are incorrect. In the wrong order, or something, I forget.They might work under another OS, but not this one. Did you try changing the command line configuration in CB to this: $linker -o $exe_output $libdirs $link_objects $libs $link_options
It works. No seriously. Just do it, you'll thank me. Alternatively, you could go through that entire process that I did in the course of this thread. It's up to you man. Save yourself and run now.
I changed all command line macros such that the pattern followed your suggestion of "$linker -o $exe_output $libdirs ..."
I still get the crt2.o not found error with TDM gcc 4.2.1 on Windows XP.
Quote from: Pecan on July 14, 2008, 07:02:35 PM
I still get the crt2.o not found error with TDM gcc 4.2.1 on Windows XP.
This will only, and I mean
only, result from an improper MinGW installation. Remove any and all environment variables relating to MinGW/GCC (including PATH entries), reinstall MinGW in an empty directory, and add an entry for the bin subdirectory to PATH (typically C:\MinGW\bin).
If an improperly installed GCC exists anywhere in PATH (or, for 4.2.x and earlier, in /mingw), you WILL have problems. Do NOT install MinGW on top of mSYS or mSYS on top of MinGW. Do NOT have Cygwin and MinGW in PATH at the same time.
If you only ever run MinGW/GCC from Code::Blocks, you don't even need an entry in PATH. No environment variables whatsoever are necessary.
Cheers,
John E. / TDM