I have been confused by C++ Builder 2010 assuming my library is dynamic. I did not find any options or help in documents regarding what I need to change in the project to build static library.
Now I produce DLL, but I need to produce LIB, so I can just link it to the project and forgot about DLL. BTW it produces LIB, but for dynamic linkage only.
Did you tried Project Props -> Config properties -> Config Type -> Static library (.lib) ?
I know this is old but AFAIK Delphi 2010 doesn't support .bpi (static) files. It was removed at some point. This has been a ballache for us too, as we have a large project that we want to break down into units and for various reasons dynamic libraries won't cut it.
You have to choose "Static Library" when you create the project. You can't convert it once the project already exists. This will create a statically linked library. It should be easy to add your existing source files to the new project and just build.
Related
I'm using MCS to compile some code into a DLL. Plain console compilation, no Visual Studio or similar. That works, the DLL works well.
But I'd also like to add some meta data to the DLL, so that (under Windows -> File properties) the company name and version etc. are visible.
I already tried around with .resx files, created some but that didn't help. Maybe I misunderstood the resx-thing.
The way I did it with the resx file: create a new text file, add the lines
# A list of personal data
company=myCompany
So I guess that was wrong.
How can I add such meta data to my DLL?
Thanks, K1
A is a module project. There are some test targets and the relevant reusable code is compiled in a separate (static library) target. A uses the third party Lumberjack logging library. The Lumberjack code was simply dropped into the project.
B is a different module project, but otherwise it has the same properties as A.
C is the main project. It depends on A and B. It links the libraries of A and B.
Compiling C will result in duplicate Lumberjack symbols.
How can I have multiple separate module projects so that...
they don't know of each other,
use the same third party code,
can be compiled and tested on their own,
included in a main project without duplicate issues?
So, to elaborate on sergio's answer, I was able to succesfully build a test setup as follows.
I included the Lumberjack code in a separate project that builds Lumberjack as a static library.
I created a new project ProjectA with a static library target ModuleA and a test app target DemoA. I copied the Lumberjack project folder into the project folder of ProjectA and then added it as a subproject. I didn't make ModuleA dependent on Lumberjack or link Lumberjack in ModuleA. Instead, I made DemoA dependent on both and link both libraries. This way, I am able to compile the test target, but the library target doesn't include Lumberjack.
I created a second project ProjectB with the analogue setup as ProjectA.
In the main project, I included ProjectA, ProjectB and Lumberjack as subprojects. Unfortunately this will make Lumberjack included 3 times in the main project, which is a little bit inconvenient and ugly (for instance when selecting dependent targets, you can't really tell which one is which).
Finally, I made the main project's target dependent on Lumberjack, ModuleA and ModuleB and link all three libraries. Now, the main project can compile without duplicate symbol error and the submodules can also be compiled and tested on their own.
Since you are targeting OSX, the solution to your issue is building Lumberjack as a framework (as opposed to link the sources code in your A and B modules) and then using that framework wherever it is required (i.e., in any project using A or B modules).
Indeed, Lumberjack already includes a project that will build a Lumberjack.framework, check this: CocoaLumberjack/Xcode/LumberjackFramework/Desktop/Lumberjack.xcodeproj.
Elaborating more on this, you would define your A and B modules as you are doing now, but without dropping Lumberjack source code in it.
What you do instead is, whenever you want to use the A static library in a executable (say, your test target), you add the library to the target and also the lumberjack framework (exactly as you do with OSX SDK frameworks).
Adding the dynamic framework is just a different way to "drop the sources", if you want, but done properly.
When you want to use both A and B in a C project, you add both static libraries and your Lumberjack framework to C.
As you can see, this way of doing will comply with all your four requirements, at the expense of introducing one dependency: you need to make clear in your static libraries documentation that they depend on the Lumberjack framework. This is actually not a big issue, since the latter is available in its own project and any one will be able to build it on his own.
If you want to improve on the handling of this dependencies, cocoapods are the way to go (a cocoapod is a file associated to your library which describes its dependencies, so when you install your library, the cocoapods system will automatically install also the dependencies). But this is highly optional. One single dependency is not a big issue to document or comply with.
Hope this answers your question.
I hate to reference an existing answer but here's one solution that's cumbersome but works: What is the best way to solve an Objective-C namespace collision?
I have this same problem and I'm working on a better solution though. Another idea that might work but I'm not yet sure how to implement it I asked here: Selectively loading classes in Objective-C
A third idea I had because of something someone said on my question was to wrap one of the libraries in a framework and create functions that reference the functions you need. Then load using something like #import <myFramework/MFMyAliases.h>
Have you tried looking at the libraries with ar? If you are very lucky, running for example
ar -t libA.a
gives you a list of files like
__.SYMDEF SORTED
Afile1.o
Afile2.o
Lumberjack1.o
Lumberjack2.o
Afile3.o
SomeOtherLibrary.o
where the Lumberjack files are clearly separable from the rest. Then, you can kick them out
with
a -d Lumberjack1.o Lumberjack2.o
and link C against this trimmed library while using the full library when testing A alone.
I was trying to achieve the same thing before few months and "Easy, Modular Code Sharing Across iPhone Apps: Static Libraries and Cross-Project References" article got all what i needed. please check it out if its useful.
Are A and B binaries?
If not you could simply uncheck the compile checkbox for all *.m files of one of the projects, so as to avoid building duplicate objects.
Also if you could use A and B thorough Cocoapods it would be best.
Try this.
It is sharing libraries/modules between different projects.
Before anyone bashes me with, read this first and that second, I have tried following links below to achieve internationalization with MFC.
Creating resourse DLL:
Localization of MFC Components
http://msdn.microsoft.com/en-us/library/x6h91d9w.aspx
Localization for older MFC
htp://support.microsoft.com/kb/198846/en-us
I am new to MFC so please be kind with your answers. So in order to get localization with MFC 7 and above I followed these steps. (Currently using MFC with Visual Studio11)
Created a MFC Project (MyApp) with MFC in a shared DLL
To add a another language (German) to the app, I created a win32 Dll project (MyAppDEU)
Copied the resource file (MyApp.rc) inside same folder and renamed it MyAppDEU.rc
Added the MyAppDEU.rc file to the dll project
In resource view of MyAppDEU.rc, changed the VS_VERSION_INFO -> Block header to "Deutsch (000704b0)"
Changed some strings in the string table to see the difference when the main app loads
Changed the ouput of the MyAppDEU project to build inside the MyApp Output folder
Compiled MyAppDEU to get the Dll
Compiled MyApp with and without following the instructions from point 9
http://support.microsoft.com/kb/198846/en-us
So with all these done, I failed to see any difference in my Application. It loads with the English resouce file which I created the App with. My computer has a German Windows 8 OS. From what I know MFC has inbuilt multilanguage support with Satellite Dlls. I have the correct naming format ApplicationNameXXX.dll. The dlls are in the same directory as the exe.
I hope someone can see what Im doing wrong or missing here. I am fairly new to MFC and appreciate any help regarding this.
[answer adaapted from this SO answer]
I have used a slightly different approach successfully, skipping the MFC inbuilt multilanguage support with Satellite DLLs.
We have multiple DLL projects in our solution, each one containing just one set of resources for a single language (e.g.: AppRes_ENU.DLL). At run-time InitInstance(), we select the appropriate language DLL with code like
CString sResourceDllName;
// format sResourceDllName according to the language ("%s\AppRes_%s.DLL")
hInst_aRes = LoadLibrary(sResourceDllName);
if (hInst_aRes == NULL)
{ // handle <resoure-DLL not available>
return FALSE;
}
AfxSetResourceHandle(hInst_aRes);
and use hInst_aRes to load strings, dialog boxes, ...
Have a look at this software: http://www.apptranslator.com/ . It helps with localisation using satellite dll's; the documentation probably describes how to do it. It's quite simple once you figure our the relationships between ::AfxGetResourceHandle() and hInstanceHandle and all that jazz - the easiest way to learn about that is to read the MFC source. Then you write a few helper classes and off you go :)
will appreciate any pointers here.
I am creating a Solution that have multiple Projects.
The solution have various class libraries that I create (libCore, libApplication, libUser).
One project in the Solution is webApplication-A that will dynamically compile some VB.Net codes (input from user).
Problem: I cannot figure out how to add the assembly of one of my library to be used by the dynamic code, in this case libUser.dll.
I have already added libUser as a reference to the webApplication-A project (which is compiling the code).
I can see that libUser.dll is in the project's Bin directory.
Dim voCompiler As New Microsoft.VisualBasic.VBCodeProvider
Dim voCompilerParams As New System.CodeDom.Compiler.CompilerParameters
voCompilerParams.ReferencedAssemblies.Add("mscorlib.dll")
voCompilerParams.ReferencedAssemblies.Add("libUser.dll") '<<=== Cannot load this assembly
You need to pass the full path to the assembly:
voCompilerParams.ReferencedAssemblies.Add(GetType(SomeType).Assembly.Location)
I am trying to use a static library in a project. The static library depends on several frameworks... CoreData, CFNetwork, AddressBook, etc.
The static library also uses categories, so I am forced to use the -all_load linker option in the main project's "Other Linker Settings". When I enable this, I get 120 errors all relating to my main project not being linked with the same frameworks as my static library (CoreData, CFNetwork, AddressBook, etc).
It is very inconvenient for a developer to want to use a static library, link to it, but then still be required to link to all of the frameworks that the library links to. Is there any way to automate this process, so that the main project automatically links to all of the frameworks linked to by the static library?
I am using XCode 4.4.
edit: to be more clear, I have the following:
StaticLibrary.xcodeproj
- AFNetworking
- files...
- CoreData
- categories for NSManagedObjectContext, for convenience
- AddressBook
- convenience methods for working with contacts
This project's target is linked to the necessary frameworks under Build Phases > Link Binary With Libraries. This includes CoreData.framework, AddressBook.framework, etc.
Now what I would like to do is add this library to another project of mine. In fact, I would like to add this library to every new project I make from here on out, so I always have easy access to the convenience functions/categories that I've written. So: I add the library to my project, and then add the .a file to Build Phases > Link Binary With Libraries (of my main project). I also do everything else necessary that I know of (see comments).
What I would like to happen: the main project is now linked to the library, so it inherits all of the library's links so that the main project is now also linked to CoreData.framework, AddressBook.framework, etc.
What does happen: the main project gives me errors because it is not linked to anything that the library requires.
Is there a way to automatically add the linked frameworks from the static library to the main project, or should I split the library up into CoreDataStaticLibrary, etc, and then require the developer to add CoreData.framework as well as the static library to the project target everytime?
As I understand, you should only need -all_load if your library contains only categories. Otherwise, you can use -ObjC. That's what I use, at any rate.
Also, when you build a static library, you are just creating an archive of compiled object modules. No external dependencies are resolved in the library. Really, you should just think of it as a single collection of a bunch of object code files.
So, when you finally link your executable, it will link all your compiled code, along with the archive of pre-compiled code in your static libraries. The linker will expect to resolve all symbols, so you must tell it where to find all the libraries (frameworks) that are needed to completely resolve all the symbols.
Should XCode be able to look inside a static-library subproject and pull out the framework dependencies from that project and add them to the linker invocation for the final project? Sure. But, I'm not aware of a way to make that happen automatically.
If you want, you can create a podfile for your library, and use CocoaPods to manage your project dependencies.
The problem is you're including the same symbols several times. I've run into the same issue several times and the solution is basically to understand what the "-all_load" flag does, which is pretty well explained in this SO question: What does the all load linked flag do
Said that, you never reference frameworks from your library in that way. Since these frameworks are dynamically linked they don't really belong to your static library, there are just references pointing to them on it.
The user of such library should be responsible of adding the necessary frameworks to make it work properly. This means, you don't have to link your library to such frameworks (as such thing just doesn't make sense), just add them to project that's gonna use it. (Have a look on Restkit to see how it's done).
Also, I think you could get rid of the "all_load" flag and try to replace it with "force_load /path/to/the/library" all_load is only necessary in case your library only contains categories (no classes at all).
Let us know how it goes and happy coding!