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.