I am working on a buildroot project to make a small custom os. I only include the absolute necessary packages. One of the things I add is a precompiled program that uses certain libraries that are not included on the system. I want the system to include them, but I cannot find them in the buildroot menuconfig, linux-menuconfig or busybox-menuconfig.
So my question is:
how do I add libraries to my system in buildroot?
I have tried searching for them in the menuconfigs and I have also tried to find information about this in the buildroot manual.
The libraries I want to include are:
ld-linux-armhf.so.3
libdl.so.2
libc.so.6
After some searching I have found that:
ld-linux-armhf.so.3 is actually a symlink to a ld-2.*.*.so library
A version of libc is included on my system (libc.so.2).
The libraries you list are part of the C library, itself part of the toolchain. Buildroot will always provide those libraries, either by building a toolchain itself (what we call the internal toolchain backend) or by using an existing toolchain (what we call the external toolchain backend).
Related
I'm trying to build and package LCM with Bazel. This works for the "build" part, but the end result is a library not usable by external consumers (i.e. "package" fails, because the package is broken).
LCM uses glib, which I am importing with pkg_config_package (gory details). More particularly, LCM uses glib internally, but does not expose this to users. This means that consumers should not need to link glib; liblcm.so should do that, and consumers should only need to link to LCM itself.
This all works great with upstream (which uses CMake and Does The Right Thing). Bazel, however, seems to be not linking liblcm.so to glib, for some unknown reason. If I build an executable with Bazel within the same overall environment, Bazel seems to know that users of LCM also need to link to glib. However, when I try to package this LCM for external use, it is broken, because liblcm.so isn't linked to glib, which forces consumers to deal with LCM's private glib dependency.
Why is Bazel not linking the LCM library to glib, and how do I fix it?
(p.s. We have similar issues with libbot...)
Apparently, this is a known issue: https://github.com/bazelbuild/bazel/issues/492.
I can't just make the cc_library a cc_binary, either, because — while that would fix the under-linking — then I can't use the library in other Bazel targets. Nor can I make a cc_binary that wraps a cc_library, because then internal and external consumers aren't using the same library.
Static libraries do not link with other static libraries. When building through Bazel, Bazel keeps track of the dependencies and will link against all dependent libraries when building the executable.
There's more information here about linking static libraries:
Linking static libraries to other static libraries
One interesting suggestion brought up is unarchiving both libraries and then creating a new library with all the .o files. This could possibly be achieved in a genrule.
I'm completely new to iOS development and coming from an Android background. I was starting to look at what alternatives are out there for dependency management in iOS and found out that CocoaPods seems to be the most prevalent option.
After reading a lot of links about this topic I'm kinda at a loss and wondering what is the usual way dependencies are handled in iOS.
I have two questions:
1) What would the equivalent of using gradle to generate library (.aar) projects be in iOS? If there's any equivalent option. From what I've seen one can wrap static libraries and headers into frameworks and these can be used in other apps, is this the standard way to do it?
2) If (1) is correct, does CocoaPods offer a mechanism to add frameworks as dependencies?
I don't have a Android background but from what I understand of .aar files CocoaPods does something very similar. CocoaPods uses .podspec files (described here) to generate static libraries (and soon dynamic frameworks which are new in iOS 8) that are then linked into your project.
A podspec can define source files, assets, libraries, or frameworks that a source vendors for linking into your application. So yes it does support adding frameworks as dependencies, although until iOS 8 frameworks were not supported at all on iOS.
As far as the 'standard' way to do it, I think that's based on opinion. There are a few general ways to include dependencies you can choose from.
Drag files, frameworks, and whatever else you need into your project manually. Updating these is more difficult and that also means you have to configure your .xcodeproj depending on what features that library needs (such as ARC)
Drag a provided .xcodeproj into your project, and link the relevant target from the given project. This can be nice if the library provides a project that can build a framework or static library, in this case you'd pull in that library but their project would handle custom compiler flags.
Do either of the above while including them as git submodules. Assuming nothing massive changes in the project this helps a lot with updating your dependencies.
Use CocoaPods. CocoaPods will handle all the custom linking and updates based on semantic versioning (usually).
Use Carthage. Carthage is an in- between CocoaPods and the .xcodeproj solution. It will download code based on semantic versions defined by git tags, then you drag the generated frameworks into your project.
All of these options have pros and cons and the decision normally comes down to how you feel about the control you have over the inclusion of the library, and how automated you want it to be.
I do not have android nor iOS background however I've been developing a CI tool for both platforms and here are the answers
As You mentioned this a framework and pods (libraries) from cocoapods are distributed that way. For instance, have a look at Apphance. When spec is clicked it's visible that this library will be accessible as a Apphance-Production.framework.
You add pods to Podfile and download them with pod install command. This command will made classes from Apphance accessible from the code. Some people do commit downloaded pods, other not (it's like adding jars or aars to source control).
I am working on a static library, called Silicon, that I use for all of my iOS apps.
Because I don't want to create one massive static library that could become hard to maintain I create lots of smaller static libraries that I attach as submodules.
As of the time of this writing the dependency tree for Silicon is as follows:
Silicon
|
|==> FDKeychain
|==> FDDataClient
|
|=> FDRequestClient
|
|=> FDFoundationKit
|==> FDSQLiteDatabase
|
|=> FDFoundationKit
As you can see both FDRequestClient and FDSQLiteDatabase have FDFoundationKit as a common static library.
What seems to happen is that when a project using Silicon is built it builds all of Silicon's target dependencies to the projects build directory. The same thing happens for FDDataClient and FDSQLiteDatabase. So at some point FDFoundationKit from FDRequestClient is built and copied to the build directory as well as FDFoundationKit from FDSQLiteDatabase. Whichever one is built last just overwrites the previous one.
Just by sheer luck FDFoundationKit hasn't been changing in any serious ways such that FDRequestClient and FDSQLiteDatabase can't always be using the same version but I can't guarantee it will be like this forever.
I am trying to figure out if there is a way for Silicon to specify which version of FDFoundationKit to use so it can be Silicon's responsibility to ensure that the the version used will work for both FDRequestClient, FDSQLiteDatabase and any other dependencies I add in the future.
I know CocoaPods attempts to solve this problem but I do not want to make someone have to setup all of that just to get my library working. If I could just find someway of having Silicon define which version of FDFoundationKit to use everything would work perfectly.
You could (as we do) place all of your libraries into frameworks, as frameworks support versioning. Frameworks are just a directory tree configured in a common manner. Xcode does not directly support the creation of frameworks, so you have to create them in a script, typically as the last of your build phases. An example (thanks to jverkoey) can be found at IOS- framework
Within a framework you may store all versions of each static library within the
myLibrary.framework->Versions->n.n folders.
The myLibary.framework->Versions->Current is a link to the folder of the latest version.
Since you are using static libraries, Silicon itself cannot specify the versions (that would require dynamic libraries), however the build, linker or environment flags used for the building of Silicon certainly can.
In this manner, by default, Apps will always use the latest version of the library, but the actual version linked may be easily overridden by linker flags when building. Also, all users will simply include the Silicon framework in their project in the same manner as any other framework, so it's very simple for developers.
There looks to be only two answers to this problem:
1) Use a dependency manager like CocoaPods or Carthage.
2) Any static libraries or frameworks you release should not have any target dependencies. They should link against any dependencies you have and it is the responsibility of person integrating your library to also integrated the required dependencies.
I've created iOS Framework project using this method: https://github.com/jverkoey/iOS-Framework
Works pretty neat but I'm a little confused on how to include libraries/frameworks that are needed by my framework to work and, in particular, how to do it so that in case 3rd party client app that uses my framework can include these libs as well without conflicts.
Let's say my framework code needs these two things:
FacebookSDK.framework
libFlurry.a
The first one is an iOS Framework. When I add it to "Link Binary With Libraries" phase in my Framework and try compile the client project that uses my framework the linker complains about missing symbols - I need to add FacebookSDK to the client project which is great: there is no possibility of conflicts if client apps wants to use Facebook.
However when I do the same with Flurry static library I get duplicate symbols error when compiling client project. Which confuses me a bit, because isn't FacebookSDK.framework just a packaged static library?
ukaszs-iMac:FacebookSDK.framework lukasz$ file Versions/A/FacebookSDK
Versions/A/FacebookSDK: Mach-O universal binary with 3 architectures
Versions/A/FacebookSDK (for architecture i386): current ar archive random library
Versions/A/FacebookSDK (for architecture armv7): current ar archive random library
Versions/A/FacebookSDK (for architecture cputype (12) cpusubtype (11)): current ar archive random library
So my questions are:
why a library embedded in framework (like Facebook) is not linked to my Framework project product, whereas library included as .a file is?
how to include .a file in my framework so that it does not produce duplicate symbols error when client app using my framework also needs this particular static library?
For the use case you are describing, you should be linking to these external libraries from your application, NOT your own framework. It can be one or the other, but it can't be both.
If you decide that these dependancies belong as the responsibility of the application, you would remove them from "Link Binary With Libraries" and any other explicit linking configuration, and just project your framework project with the path to these frameworks and libraries so it can find the symbols (but not link against them) at compile time (i.e. the path to the libraries should be included LIBRARY_SEARCH_PATHS).
Use cocoapods , it's easy (http://cocoapods.org/)
Your application developers will have to include the podfile and download the dependencies.
While developing your SDK use a reference application/demo app on top of the SDK to simulate this.
You shouldn't link anything when building your framework but just create a *.a binary with your framework's objects.
Also you should not include code from other libraries in your framework as client applications may be adding the same libraries directly or requiring different versions of them, thus creating conflicts.
Off course you can reference *.h header files from other libraries in your framework in order to compile your objects.
As a result the installation steps for your framework should detail other required frameworks/libraries needed, their supported versions, how to add resource files (if any), etc. Just some of the many reasons why you may want to consider Creating a CocoaPods' podspec instead.
You should use CocoaPods. Your dependency on Facebook can be done by linking against the CocoaPod.
If you want to include that particular version of Facebook in your pod, you can put it in your repo and use the vendored_frameworks property to refer to it.
Similarly if you wanted to vendor libFlurry.a, you could do so using s.vendored_libraries.
For system libraries, you don't need to vendor them, e.g. libZ.a.
I strongly recommend creating your CocoaPod using pod lib create YourPodName. They've recently changed the mechanism for how this works and it's really nice.
You can create an Example project that shows how to use your code in context of an app.
Then one of the other neat things I just learned about, someone can do pod try YourPodName and it will automatically download, integrate and run the Xcode project.
CocoaPods is worth the trouble.
I am building my framework project using CocoaPods.
The framework uses some 3rd libs from CocoaPods.
Podfile specifies to install dependency on target of the framework.
When I build the framework, it includes all libs in the binary.
If I add use_frameworks! in Podfile, when the framework is built, it will not include 3rd party libs.
Use CocoaPods dependancy manager. Here's a good guide,
7 miniute video tutorial
Mostly if you install third party frameworks you can install with cocoapods (which is really nice, I would definitely do that) or they offer you to download the framework and include it in your Project.
If you decide to download the library and include it there is normally a list of frameworks you need in the "Getting started" guide.
Means: Offer them to install using cocoapods and to download your library but do not include anything else, give them a list what they need.
I am currently building a library which should be used internally in a few iOS projects but should also be distributed to customers accessing our services with the library. The Library itself consists purely of C++ code and I am basically able to create Apps with it on iOS which work fine. My problem is creating a single, easily distributable file that can be given out to customers which can easily install them, use the provided headers and don't need to have the headaches that I am currently facing when it comes to linking.
Our code depends on two other projects, namely boost and websocketpp. For boost there is the script on github which I took to generate a framework. For websocketpp, I imported it into XCode and used the scripts from this github project to build a framework. I added both frameworks to my (potential) framework as dependencies and used the same script to build one.
I have an app using my library as a sub-project working fine. Even including the framework into the project and running it on a device works fine. So far so good.
However, trying to create an archive of the App project lead to several questions and headaches.
My library did not seem to contain the code for all architectures. So I tried to archive the Framework projects, which after small modifications in the build scripts to use different locations to search for headers worked fine.
It does not seem to contain all binary code or references to local files (i.e. my specific location of boost). I gathered that from Linker errors that I still get that tell me that some boost calls could not be satisfied.
The second issue made me think that I am must be doing something fundamentally wrong and my intuition tells me that it can't be that difficult and "hackish" to create frameworks or libraries for others for iOS development.
As you probably have found out by now, I am not very experienced when it comes to iOS and I am wondering if I am missing something fundamentally. So, I am sure that this question is rather broad, so some more concrete questsions:
Is there a(nother) way to generate some kind of distributable (preferably a framework) which contains: my public headers, my binary code compiled for all platforms supported for iOS development, the binary code of dependencies?
Is the only way to do that by adding some handwritten scripts to the build process?
I have the feeling that the information I found is quite outdated since it's older than a year and mostly refers to Xcode 4.2 or 4.3 -- so has there anything changed in this regard recently?
For example one error I get is:
File is universal (2 slices) but does not contain a(n) armv7s slice: <file>
The <file> slice is the path to the file in the framework in the Products folder of a different XCode workspace (the library was build in a different workspace then the app). I dropped the framework folder into the project for this test from a completely different location.
What is going on here?
Why does it keep referencing to some internal XCode directory?
How do I properly export it?
Since I guess my setup is probably skrewed up and weird from all the different things I tried up to now: How does this setup look like in a ideal situation?
Yes, there are some questions regarding this on SO already, however, either I don't see or don't understand in those replies:
...how to handle depencies of my code to other third-party code properly.
...how to generate a distributable file.
Have you checked your project build phase under Compile Sources and Copy Files to see if you are including your framework source files in your build?
You may also try the C/C++ Library template under OSX -> Framework & Library.
Finally, there's also kstenerud’s iOS Universal Framework, which I found very useful. I wrote a few articles in my blog on using it.