crt2.o / Vista headaches, now with -v goodness.

[ironlizard]

Code

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 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.

[ironlizard]

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:

ld -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.

[rickg22]

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).

[ironlizard]

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

[mariocup]

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

Code

	 #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

Code

	         /* 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

[ironlizard]

Very cool, thanks mariocup.

I may try that after/if I get wxwidgets to compile, getting the gcc cc1 error now  :!:

edit: Fixed

[ironlizard]

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?)

ld: 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:

wxmsw28.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?

[raph]

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.

Code

mingw32-make -f makefile.gcc BUILD=debug UNICODE=1

[ironlizard]

OK, can do. I originally compiled using the instructions found at 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.

[ironlizard]

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.

[ironlizard]

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?

[ironlizard]

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.

[ironlizard]

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 I will know more.

Edit: I take it back, these undefined errors are different.

[ironlizard]

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)

[ironlizard]

It's no good, even after integrating. I'm going to try this wxpack thing next.

[ironlizard]

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)
(bottom of the page)

As follows:
 

undefined 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.

[ironlizard]

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!

[net]

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

[ironlizard]

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.

[theultramage]

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:

ld -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

ld -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?

[ironlizard]

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.

[Pecan]

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.

[TDragon]

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