I have been haunted by this ghost problem for a long time. I have a component library that I wrote myself, containing some derived VCL components.
Whenever i try to run an application that uses this library (MyComponents.bpl), it will show this error:
Mbutton used to be one of the components in the library, but it has long obsolete and removed from the project.
I have checked all files (cpp and h files) in the MyComponents project, none of them has any reference to Mbutton.
The host application source code is not referring to this component as well.
And I have been very sure there is only one copy of MyComponents.bpl in my whole PC. (which is located in the folder where the application is uisng it.)
There is no duplicate in Windows/System32.
Cleaning/Uninstalling the components library and recompiling/Re-installing it does not help.
Can anyone help me track down what's the cause of this ghost component problem, please? Many thanks.
Ah, found the source of the problem... There is a MyComponents.LIB which is referencing Mbutton component. The compiler was complaining about MyComponents.BPL, so I was misleaded all the time.
Removed the reference to MyComponents.LIB in the cbproj file and gone with the problem. Just to be sure, I deleted the LIB file as well.
This PC wasn't my original development PC, it was used by my colleague who has resinged, and I took over the PC after my PC has broken down. Don't know why she took my BPL and convert it into LIB... sigh, problem solved, thanks anyway to all who helped.
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.
I am attempting to convert parts of an Android app to iOS using Doppl, and I am getting a strange result: Doppl keeps trying to pull in android.arch.lifecycle:reactivestreams, even though I don't want it to.
Specifically, in app/build/j2objcSrcGenMain/android/arch/lifecycle/, there is a reactivestrams/ subdirectory with R.h and R.m files in it. This seems to make Xcode cranky and may explain why I had some oddities with pod install.
My app/build.gradle has compile "android.arch.lifecycle:reactivestreams:$archVer", because my activity is using LiveDataReactiveStreams.fromPublisher(). However:
The activity is not in the translatePattern (and since its code is not showing up in app/build/j2objcSrcGenMain/, I have to assume that the translatePattern is fine)
I do not have a doppl statement related to reactivestreams, because there does not appear to be a Doppl conversion of this library (nor should it be needed here)
AFAIK, nowhere else in this app am I referring to LiveDataReactiveStreams, which AFAIK is the one-and-only public class from the reactivestreams library
So, the questions:
What determines whether Doppl creates R.h and R.m files for some dependency? It's not the existence of a doppl statement, as I have doppl statements for a lot of other dependencies (RxJava, RxAndroid, Retrofit) and those do not get R.h and R.m files. It's not whether the dependency is referenced from generated code, as my repository definitely uses RxJava and Retrofit, yet there are no R files for those.
How can I figure out why Doppl generates R.h and R.m for reactivestreams?
Once I get this cleared up... do I re-run pod install, or is there some other pod command to refresh an existing pod with a new implementation?
Look into 'app/build/generated/source/r/debug' and confirm there's an R.java being created for the architecture component. It'll be under 'android/arch/lifecycle/reactivestrams'.
I think there are 2 problems here.
Problem 1
Somehow Doppl/J2objc is of the opinion that this file should be transpiled. It could be either that 'translatePattern' matches with it, or that something in the shared code is referencing it. If you can't figure out which, please post a comment and I'll try to help (or post in slack group).
Problem 2
Regardless of why that 'R.java' is being sucked into the translate step, because of how stock J2objc is configured, the code is being generated with package folders instead of creating One Big Name. That generated file should be called 'AndroidArchLifecycleReactivestramsR.h' (and AndroidArchLifecycleReactivestramsR.m). Xcode really doesn't like package folders. That's why there's a slightly custom J2ojbc being used with Doppl, so we can have files with big names instead of folders.
In cases where you intentionally use package names that match with what J2objc considers to be "system" classes, you need to provide a header mapping file to force long names. The 'androidbase' doppl library needs to add a lot of files that are in the 'android' package, which J2objc considers "system". We override those names in the mapping file.
build.gradle
https://github.com/doppllib/core-doppl/blob/master/androidbase/build.gradle#L19
mapping file
https://github.com/doppllib/core-doppl/blob/master/androidbase/src/main/java/androidbase.mappings
I screwed up.
In my dopplConfig, I have:
translatePattern {
include '**/api/**'
include '**/arch/**'
include '**/RepositoryTest.java'
}
In this case, **/arch/** not only matches my arch package, but also the arch package from the Architecture Components.
Ordinarily, this would not matter, because the Architecture Components source code is not in my project. But, R.java gets generated, due to resources, and the translatePattern includes generated source code in addition to lovingly hand-crafted source code. So, that's where my extraneous Objective-C was coming from.
Many thanks to Kevin Galligan for his assistance with this, out on the #newbiehelp Doppl Slack channel!
I have checked the updated code from the weibsite: http://sourceforge.net/projects/clipsrules/
When I build the CLPSStactic project, there is an error displayed in the output window:
..\clipscpplib.cpp(281):error C2664:
"EnvAddRouterWithContext": cannot convert parameter 4 from "int (__cdecl *)(void *,const char *) to "int (__cdecl *)()""
Notes：
I use the VS2012 version
Using VS2012 open the CLIPS.sln(in the folder named "Installer")
has errors in updating to vs2012(CLIPS.vdproj, CLIPSSource.vdproj). But the CLIPS's source code has generated in the folder ../Source/CLIPS.
CLIPSDynamic and CLIPSWrapper can be compiled without errors.
I want to know why this error come out, is it related to the VS version or anything else? How to solve this?
Thank you!
#Gary Riley
If you have time, please take a look at this. Thank you!
You're using the wrong projects/solutions. Download the latest commit (r281). The solution folders in the microsoft_windows directory that you want to use are CLIPS_MVC_2010, CLIPS_MVC_2013, Examples_MVC_2010, and Examples_MVC_2013. Since you're using Visual Studio 2012, you'll probably want to use the 2010 directories. The instructions in the Advanced Programming Guide specifically reference these directories. Don't use anything in the Installer directory. You'll need to copy the CLIPS source code files from the core directory to the microsoft_windows/Source/CLIPS directory since these aren't replicated in the repository.
I have solved this problem by myself. There's the details:
Copy the "router.h" and "router.c" files from the folder "core" (http://sourceforge.net/p/clipsrules/code/HEAD/tree/)
to the folder "microsoft_windows/Source/CLIPS", and delete both origin files in the folder "../CLIPS".
Don't copy all the files in the folder "core" to "CLIPS". it won't make the CLIPSStatic project built successful either. It seems there are problems in "aggenda.h" or "aggenda.c" of the folder "core".
I think the problem is that the "router.h" and "router.c" generated by the project CLIPS in the folder named "Installer" isn't the newest version.
If you have check the code from the same website, and used the same version VS. you may encounter this problem too. And this manner can help you to solve the problem.
I got this error using Visual Studio 2008 and I found a solution on the web here and here. But I can't find out how to configure link.exe.
How can I set the /expectedoutputsize:600000000 option for linker.exe in VS2008? I searched in the project properties in the Linker section, but I can't find the place...I searched in the solution and in Visual Studio options. I found the linker.exe.config but I don't know the schema.
My problem is not the disk space, I have plenty of disk space. Any help?
The option must be added in the Project Settings->Librarian->Command Line->Additional options: text box.
Sorry to resurrect this old thread, but I had a similar problem yesterday, and my solution had nothing to do with anything I found online. This is the first SO post that comes up, so I figured I would contribute in case anyone as the same problem.
Here is how I ran into the problem:
I originally had a project that created an exe:
MyProject.vcxproj -> MyProject.exe
I then turned the original project in to a .lib project by splitting main.cpp out to a separate .exe project. I set the target name for the exe project to be the same as the lib, so that we wouldn't change our executable name. I also added a different .exe project that uses the library but has a slightly different main.cpp
MyProject.vcxproj -> MyProject.lib
MyProjectVariant1.vcxproj -> MyProject.exe
MyProjectVariant2.vcxproj -> MyProjectVariant2.exe
The way our solution is currently laid out, all of the projects dump their targets into the same output directory.
The problem was that both the .lib and first .exe share the same target name, so any secondary files (pdb files, iobj, ipdb, etc.) would get overwritten. MyProject.exe would literally overwrite these ancillary files before it could link in the MyProject.lib.
Conclusion:
I "fixed" the problem by using a unique target name for the first variant. We will also review our build strategy to see if we should be using different output directories for each project instead of slamming them all together in the same location. Seems more logical to give them different target directories.
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.