I'm working on a project that creates a DLL in C for Windows CE 5.0 using STANDARDSDK_500. The project is relatively simple with just one C source file. What I've noticed is that when I clean and build the project using Visual Studio 2005, it fails to create my Import lib. When I tell Visual Studio to rebuild it, it correctly creates the import lib.
Turning on verbose linking, I discover that in the failure case (clean and build) CVTRES.exe is discarding my functions, like so:
Invoking CVTRES.exe:
/machine:thumb
/verbose
/out:"C:\...\Temp\lnkC7E.tmp"
/readonly
/windowsce
".\standardsdk_500 (armv4i)\release\WLTBApi.res"
Microsoft (R) Windows Resource To Object Converter Version 8.00.50727.42
...
adding resource. type:VERSION, name:1, language:0x0409, flags:0x30, size:892
Discarded '.idata$4' from coredll.lib(COREDLL.dll)
...
Discarded WLRegisterStartupApp from WLTBApi.obj // my functions! Oh noes!
...
This discards all of my functions, which causes the linker to not create an import lib because there are no exported functions.
I figured that the input was the .res file mentioned in the commandline - WLTBApi.res. This file is identical in the intermediate directory after trying to compile both the working way (rebuild) and the non-working way (clean. build).
So, my first question is: what are the other inputs to the CVTRES.exe program so that I can find discrepencies between the two builds?
Second: what other troubleshooting techniques would you recommend?
Additional Info - I thought perhaps the .obj files were additional inputs - they differ between the builds. I now believe that they are outputs of CVTRES.exe. If anyone knows whether or not I'm correct in this, let me know.
Okay, so I found a solution, but I'm terribly dissatisfied with it. I discovered that the project I was building had a Dependency, but one that wasn't actually a dependency. In other words, the project, WLTBApi was building a DLL, and had a dependency configured, WLTBApiLib, but it wasn't actually using any of the output of that project. By removing the dependency, the problem went away.
I'd still love to know more about how to find an actual answer to what was going on, but maybe this answer will help someone else in the future.
Related
I have been using a graphics library from Smaller Animals Software called ImgSource. Unfortunately, Smaller Animals Software has closed and is no longer available to answer questions. Recently, I had a system failure that deleted my only up-to-date copy of the library (I thought I had a backup but was wrong). I did, however, have the source code. I recompiled the library, both release and debug. (Both are static .lib files) I am also using MSVS 2019 Community edition and the project is an MFC project. The problem, and why I'm posting here, is that when I link the new release library with a previous project, the project compiles properly. However, when I build the debug version, it will compile, but not link and produces the linker error discussed LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in file.obj
A reasonable conclusion is that there is something wrong with the debug library. However, if I build a new project and link the debug library, everything works fine. So, the error does not appear to be in the library. It seems I could start from scratch and completely redo these projects, but they do reflect a tremendous amount of work.
I can't figure out how to modify the settings in the existing projects so that they will compile in debug mode. I have tried the suggestions offered in the article referenced above. Further suggestions would be greatly appreciated.
All was right in the world until I upgraded to Xcode 4 a few days ago. Since then I've had endless problems getting things to work as they should. And I have a crucial update I need to release. I've tried every permutation of settings I can think of, restarted, reinstalled Xcode, reverted to old versions of my files, everything.
My project links to three static libraries, contained in three other projects. I have used the standard processes to link libraries (drag the project files into mine, add their products as target dependencies, add the lib---.a files to the Link Binary With Libraries phase). And actually, I have no problem compiling with the Debug Build Configuration, either for the simulator or my test device.
Where everything goes sideways is when I compile with the Release Build Configuration, or when I try to Archive. I've gotten many different errors depending on my settings, but most are variations on this:
ld: warning: ignoring file
[...]/Build/Products/Debug-iphonesimulator/libGDataTouchStaticLib.a,
file was built for archive which is
not the architecture being linked
(armv6) Undefined symbols for
architecture armv6:
"_OBJC_CLASS_$_GDataSpreadsheetData",
referenced from:
objc-class-ref in ExportViewController.o
I can't understand why it's even looking at Products in the Debug-iphonesimulator directory (I swear, everything I'm linking to reveals itself in the Finder to be in the proper Release-iphoneos directory).
I have put a ridiculous number of hours into fixing this, really need help! Thank you!
Please check this question and answer. I encountered same problem and fixed it.
Xcode4 Linking Problem. File was built for archive which is not the architecture being linked (arm6)
I solved this problem by copying the .a lib files from the Release-iphoneos directory to the Debug-iphonesimulator directory so that the correct files would be found even though Xcode was looking in the wrong directory.
However, then I encountered the problem raised here of a multi-application bundle -- and the solution given didn't work for me. Finally gave up and reinstalled Xcode 3. Compiled, archived, and uploaded to the App Store in 20 minutes. Will be some time, and several dot-releases, before I give Xcode 4 another shot.
You may have -DGDATA_REQUIRE_SERVICE_INCLUDES=1 enabled in your other C flags for the GDataTouchStaticLib target. If so, add the service you need, in this case, spreadsheets, by adding -DGDATA_INCLUDE_SPREADSHEET_SERVICE=1 to your Other C Flags. Or if you don't want GData to require service includes (which will build everything into the static lib, not just what you need), just remove the DGDATA_REQUIRE_SERVICE_INCLUDES flag.
I am trying to build an old version of an application which consists of VC++ projects that were written in Visual Studio 2003.
My OS is Windows 7 Enterprise (64-bit).
When I try and build the solution I get the following errors:
error C4772: #import referenced a type from a missing type library; '__missing_type__' used as a placeholder
fatal error C1084: Cannot read type library file: 'Smegui.tlb': Error loading type library/DLL.
They both complain about the following import statement:
#import "Smegui.tlb" no_implementation
This is not a case of the file path being incorrect as renaming the Smegui.tlb file causes the compiler to throw another error saying it cannot find the library.
Smegui is from another application that this one depends on. I thought perhaps I was missing a dll but there is no such thing as Smegui.dll.
All I know about .tlb files is that they are a type library and you can create them from an assembly using tlbexp.exe or regasm.exe (the later also registers the assembly with COM)
There is also an Apache Ant build script which uses a custom task to invoke devenv.com to build the projects. This is the same script that the build server originally used to build the application. It gives me the same errors when I try and run it.
The strangest thing about this is that I knew it ought to work seeing as it is all freshly checked out from subversion. I tried many different combinations of admin vs user elevation, VS vs Ant build, cleaning, release.
I have got it to build successfully about 5 times but the build seems to be non-deterministic.
If anyone can shed some light on how this tlb stuff even works or what this error might mean I would greatly appreciate it.
I found a far more reliable solution: open the tlb with oleview.exe and then close it.
Not sure what this actually does but it works every time.
I think oleview is actually one of the samples included with Visual Studio but I haven't had the time to debug it and see what it is doing.
I ran into this error because one type library was trying to load a dependent type library, which it could not find. Even though the dependent type library was in the same directory, and even though that directory was in the searchable path, the compiler would error loading the first type library, but not mention the dependent type library in the error.
To find the pseudo-missing type library, I ran Process Monitor (procman64.exe) during the compile. This showed that after the reported type library had successfully loaded, a dependent type library could not be found. It even showed all of the places that it was looking for the dependent type library, none of which were where it should have been looking (e.g.: ).
The fix was to add a <PreBuildEvent> to the project to copy the dependent .tlb file to one of the directories that was actually being searched.
<PreBuildEvent>
<Command>copy /Y ..\Lib\Interop\CWSpeechRecLib.tlb .\</Command>
</PreBuildEvent>
http://msdn.microsoft.com/en-us/library/sce74ah7%28VS.71%29.aspx
smegui.tlb is referencing some other tlb that the compiler can't find. If you have the .idl for smegui you might be able to figure out what the other is. I suspect the missing tlb is something that original build machine had registered but that your machine doesn't have registered.
A type library is a binary description of a set of interfaces, coclasses and enums. They're usually generated for COM components, in the case of tlbexp and regasm the tlb is created from the assembly metadata. For native COM components they are usually generated from an idl (Interface Description Language) file by the midl tool.
Edit:
I just noticed you're on x64 Windows. Are you building the project with a new version of Visual Studio? If so, are you targeting x86 or x64? If the latter, it may simply be a 32bit component that the compiler can't find (or less likely, a x64 component the x86 compiler can't find if you are targeting x86), for WOW64 the registry is virtualized for x86 vs. x64 applications.
Well I finally found out why I managed to get it to build sometimes and not others... sort of.
So long as I ran the build script with elevated administrator permissions and let that get as far as it could until that error occurred, then run the build script again as a protected administrator succeeded. Those steps must be done in that exact order with no other steps in between. If I try build in Visual Studio it does not work (although I did get it to succeed once). Probably some kind of virtualisation issue although it still doesn't quite make sense.
Well I don't need help on this any more and I know it's probably impossible to fully answer this question without knowing exactly what the build is doing. However if anyone does have any more thoughts I would happily receive them.
Cheers,
Steiny
When including "sqlite3.c" into my project, I get lots of compiler errors:
error C2027: use of undefined type "_ht" d:\...\sqlite3.c line 19556
...
fatal error C1003: Errors in the program are too numerous to allow recovery. The compiler must terminate.
When inlcuding "sqlite3.c" into an empty test project, I have no problems. I compared project settings and there are no big differences between the two projects.
How can I troubleshoot this problem? Is there anyone who had the same issue?
It looks like you're not including all its header files (or maybe you're trying to build C as C++). Don't Do That. Better yet, build it into a library (or use someone else's build) and just include the built version in your project.
Right click the sqlite3.c file in your project and select Properties. Go to
C/C++ -> Advanced -> Compile As => "Compile as C Code (/TC)"
This solves the issue. Make sure to set that under all of your Configurations and Platforms.
I ran into the same issue. I'm creating a plugin and so compiling in sqlite rather than having to distribute an additional DLL is beneficial, and this is less work than creating an additional project to build a static lib.
I'm having a weird problem when trying to register the .dll i created using regsvr32.
During development everything went fine, the debug version registers and works fine. Now i wanted to create a Release version, but that Version does not register anymore.
regsvr32 comes up with the following error:
The module "mpegsplitter.dll" failed to load.
Make sure the binary is stored at the specified path or
debug it to check for problems with the binary or
dependent .DLL files.
The specified procedure could not be found.
Some research brought me to the dependency walker, which does tell me this
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
It also does show a dependency on "crtdll.dll" that the debug version does not have (The function view shows soem functions that normally should be in ole32.dll), which is colored red'ish.
So far so good, i guess its somehow related to what the dependency walker shows there.
But where do i go from here? How do i fix it?
Any help would be greatly appreciated, that has been keeping me busy for several hours already.
Thanks!
I have the same problem. When I compared the different between "Command Line" (in Project Properties -> Linker) of Release and Debug mode, I found out that the "Optimization" options (in Project Properties -> Linker) of Release mode was turned on while ion Debug not.
Turning of Optimization for linker in Release mode solved the problem
Is it possible that the debug version is compiled with _ATL_MIN_CRT but the release version isn't? You can set this with the Minimize CRT Use in ATL project property as well.
I fixed it. It was actually being caused by the order of some mingw libraries i included to link against ffmpeg. Oh well, how weird.
In my case, the difference was in Module Definition File entry between DEBUG and RELEASE. The DEBUG version was pointing to the .DEF file where as the RELEASE had it empty.