I am trying to get libintl.so compiled on musl-based distro, but running ./configure && make in the directory containing source code, which I get from https://savannah.gnu.org/projects/gettext/ does not build any libintl objects. Furthermore, libintl.h seems to not exist in that directory as well. What's the deal?
Related
This follows on from
How do I strip and objcopy a built .so file in the Yocto bitbake compile step?
This leads back to considerable background information.
As mentioned in the previous question, I am seeking to build OCA, which I have
as a non-Yocto makefile-based project, in Yocto. The project, which builds
fine outside of Yocto, and even in Yocto, is quite complex. The issue is that it
is not cross-compiling for my target, which is aarch64 armv8-a. It is building
successfully, but for my host machine, which is x86-64. Then Yocto sensibly
refuses to package it, saying "Unable to recognise the format of the input
file".
I changed the compile flags in my makefile to -march=armv8-a, but got the error
"cc1plus: error: bad value ('armv8-a') for '-march=' switch" which seems to
mean that I can't use the host's installed gcc for cross-compiling, but rather a
cross-compiler is needed. I previously custom-added two additional layers, a
sample helloworld and mDNS (see previous questions for lots of background), and
they all cross-compiled fine, so I know that Yocto is basically set up to do it.
What is the method to get the cross-compilation to happen? Do I need to do a lot
of pervasive changes to my project's makefile system? It may not ever have been
designed with Yocto in mind.
I am looking into this: "cross-compile library recipe in yocto":
cross-compile library recipe in yocto
which seems to have some relevant information. Edit: it was only standard stuff that I had seen before; nothing about how cross-compilation gets invoked instead of the host machine's gcc.
Edit: My updated recipe, with the FILES_${PN} added and make changed to
oe_runmake.
DESCRIPTION = "OCA"
PRIORITY = "optional"
SECTION = "protocols"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI = "file://oca-1.2.7"
S = "${WORKDIR}/oca-1.2.7/Src"
# Need to override S because BitBake expects the source to be in a dir called
# oca-1.2.7 in the work dir, but it's actually additionally under Src/.
# Need a do_compile, since OCA has a makefile with a non-standard name,
# makefileOCA. Also needs non-standard flags, -f and linuxRelease.
do_compile() {
export CAP_HOME="${WORKDIR}/oca-1.2.7"
oe_runmake -f makefileOCA linuxRelease
}
do_install() {
install -d ${D}${libdir}
cp ../Obj/linuxApp/Release/OcaProtoController.so ${D}${libdir}/OcaProtoController.so
chmod 0755 ${D}${libdir}/OcaProtoController.so
}
FILES_${PN} += "${libdir}/OcaProtoController.so"
Edit: I found some info:
https://www.yoctoproject.org/docs/1.8.1/adt-manual/adt-manual.html
https://www.yoctoproject.org/docs/1.8.1/adt-manual/adt-manual.html#setting-up-the-cross-development-environment
I commented-out the setting of CC and LD in makeOCA.inc.
I did the cleaning actions of deleting the tmp folder from my build-wayland
build dir, and did "bitbake -c cleansstate oca". Then I did "time bitbake oca".
Now it looks like it is using the cross compiler.
The first error I got now is:
~/Yocto/imx-yocto-bsp/build-wayland/tmp/work/aarch64-poky-linux/oca/1.2.7-r0/oca-1.2.7/Obj/linuxApp/Release/OcaAgentProxies.a
aarch64-poky-linux-ld: cannot find crus: No such file or directory
So this is the next question: Can you tell me what "crus" means in "LDFLAGS = crus $#"?
I'm trying to build my OwnCloud client. I'm using "Generic Build Instructions" from this link - https://doc.owncloud.org/desktop/2.5/building.html.
I'm stuck at 3 step with an error:
Could NOT find Qt5Keychain (missing: QTKEYCHAIN_LIBRARY)
I downloaded Qtkeychain and compiled it using this link - https://github.com/frankosterfeld/qtkeychain/wiki.
Everything is in my C disk. PATHS are set correctly. Can someone tell me what am missing here.
Adding PATH photo:
Adding a photo to be clear what am talking about:
How did you compile qtkeychain?
With the environment variable %QTDIR% set correctly, e.g. C:\Qt\Qt5.6.0\5.6\msvc2015, you should be able to compile qtkeychain
cmake -G "MinGW Makefiles" .
mingw32-make
and get a 32bit file named "libqt5keychain.dll.a".
You can then add the directory containing this file to your Windows path environment variable. This should work (it does for Nextcloud, at least).
While compiling Swift on Mac machine, there is a dynamic library libswiftDemangle.dylib created. I need the dynamic library created on Linux machine as well, however, the dynamic library isn't created after a compilation of a source code.
The file CMakeLists.txt at lib/SwiftDemangle/CMakeLists.txt contains:
add_swift_library(swiftDemangle SHARED
SwiftDemangle.cpp
MangleHack.cpp
LINK_LIBRARIES swiftBasic)
directive, however the library isn't created.
I use this command ./swift/utils/build-script -R -c --build-subdir build --install-prefix /mnt/servers/swift/install -j4 to build the project, eventually it runs cmake and ninja to build the project.
Any ideas?
I can take a shot at explaining why the library is not getting built on Linux, even if it's late probably.
The main subdirectory containing the library you mention is:
https://github.com/apple/swift/tree/master/lib
To build the libs in that directory, which are organized in subdirectories, the following CMakeLists.txt is used:
https://github.com/apple/swift/blob/master/lib/CMakeLists.txt.
As can be clearly seen in this file, the library that you mention is only built if the system is OSX/Darwin and not in the Linux case. The relevant code in the aforementioned CMakeLists.txt is:
add_subdirectory(RemoteAST)
add_subdirectory(Sema)
add_subdirectory(Serialization)
if(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
add_subdirectory(SwiftDemangle)
endif()
add_subdirectory(SIL)
add_subdirectory(SILGen)
As you can see it,
if(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
add_subdirectory(SwiftDemangle)
endif()
prevents SwiftDemangle to be built on Linux.
A superficial double check can be to look at:
https://github.com/apple/swift/blob/master/lib/SwiftDemangle/CMakeLists.txt
which will install or simlynk only *.dylib files.
It it worth mentioning that the swift-demangle tool (different from what you asked)
https://github.com/apple/swift/tree/master/tools/swift-demangle
is built on Linux.
I have created a Yocto autotools project in Eclipse (based on a Hello World project).
I wanted to separate my code into a number of libs and then link them in a form of static libs (.a) to my project.
Now I have one app and a number of static libs. However, no matter what I try I can't get my code to compile. Each separate lib compiles and produces a .a file, but my app doesn't.
After searching the web I have a possible solution - add a direct link to my static libs:
MyApp_CPPFLAGS="-I$LOCATION"
MyApp_LDADD="/home/xxx/workspace/MyApp/Encoding2/Debug/libEncoding2.a"
This is my Makefile.am file, where libEncoding2.a exist in that path.
The error I get is:
make[2]: *** No rule to make target `"/home/xxx/workspace/MyApp/Encoding2/Debug/libEncoding2.a"', needed by `MyApp'. Stop.
I already built the lib so I am not sure why a make try is even needed.
Any help will be appreciated.
Because you use static library in your recipes, you can make a soft link to the library in your project source folder, i.e., hello-world-0.1, using following command to link to your static library
ln -s /home/xxx/workspace/MyApp/Encoding2/Debug/libEncoding2.a
and then edit your bb file, hello-world_0.1.bb, adding the source path to your URL
SRC_URI = " \
file://libEncoding2.a \
file://hello-world.c \
"
and in the do_compile block, using follow command to compile your project
do_compile() {
${CC} hello-world.c libEncoding.a -o hello-world
}
do_install() {
install -d ${D}${bindir}/Hello
install -m 0755 enet ${D}${bindir}/Hello
}
After you bitbake your project
bitbake hello-world
and run mkefidisk.sh, you can find the hello-world in /usr/bin/Hello/hello-world. Hope this hint can help you.
BTW, I am not familiar with autotools, I just use make to bitbake the recipes. And your static library should also be created in Yocto not in Eclipse I think. So I think your path for the static library maybe not correct, it should locate in ~/yocto/build/tmp/... or some where like this. In my case, it was located in ln -s ~/yocto/build/tmp/sysroots/intel-corei7-64/usr/lib/libEncoding.a depends on your target environment.
Depending on whether you're using libtool or not, you should have either a noinst_LTLIBRARIES or noinst_LIBRARIES list of targets, respectively. This should only include the name of your library (libEncoding2.la or libEncoding2.a.)
You should never use a full path for this, and you should not quote Make variables, so what you were looking for is
MyApp_CPPFLAGS = -I$LOCATION
MyApp_LDADD = libEncoding2.la # or .a
And that would work.
But on the other hand it seems like you should take some time to understand how autotools work, as it might not be what you're looking for. With a grain of salt you can take my Autotools Mythbuster as a starting point.
How do I install Helm (https://hackage.haskell.org/package/helm) on Windows 7 (64-bit)?
(Update: I had posted a lot of error messages here, but I've moved them to my answer to not clutter up the question.)
Installation for Windows 64-bit:
I'm including error messages, for if you follow all the steps up to that point and then just try to install directly. This is a conglomeration of a bunch of ad-hoc steps from following many different posts. Any simplification would be appreciated!
Note: Do all work in directories without spaces. I'm doing all work in C:/PF; modify this to your directory.
Download MSYS2-x86_64 from https://msys2.github.io/ and install it. Cabal install cairo (or helm) will give something like:
Configuring cairo-0.13.1.0...
setup.exe: Missing dependencies on foreign libraries:
Missing C libraries: z, cairo, z, gobject-2.0, ffi, pixman-1, fontconfig,
expat, freetype, iconv, expat, freetype, z, bz2, harfbuzz, glib-2.0, intl,
ws2_32, ole32, winmm, shlwapi, intl, png16, z
Download C libraries. In MINGW64 (NOT MSYS2 - I had trouble with MSYS2 at random stages in the process), use the package manager:
pacman -Ss cairo
to search for the Cairo package. You'll find "mingw64/mingw-w64-x86_64-cairo", so install that:
pacman -S mingw64/mingw-w64-x86_64-cairo
*.pc files should have been added to C:\PF\msys64\mingw64\lib\pkgconfig and C:\PF\msys64\usr\lib\pkgconfig. (pkg-config needs to be able to find these files. It looks in PKG_CONFIG_PATH, which by default should have the lib/pkgconfig folder above. Moving the file here is easiest. See Can't install sdl2 via cabal) If you get
The pkg-config package ... version ... cannot be found
errors then check your *.pc files.
Repeat with other required libraries, like atk
pacman -S mingw64/mingw-w64-x86_64-atk
(I don't know the complete list, but error messages later on will let you know what to get.)
Get the development files for these libraries (as suggested by How to install cairo on Windows). Most of them are bundled up at http://ftp.gnome.org/pub/gnome/binaries/win64/gtk+/2.22/. Unzip.
Copy files (.a, .dll.a) in lib to C:\PF\msys64\mingw64\lib. Copy the pkgconfig folder, which contains the .pc files.
Copy files in include to C:\PF\msys64\mingw64\include.
Add C:\PF\gtk+-2.22.1\bin to the path.
(2) and (3) might be redundant. I don't know - I did them both.
At this point you can probably do "cabal install cairo". (Warning: if your end goal is something else, you may not want to "cabal install" intermediate packages, see https://wiki.haskell.org/Cabal/Survival#Issue_.232_--_Not_installing_all_the_packages_in_one_go.)
See (4) for the syntax in specifying extra-include-dirs and extra-lib-dirs (but if you copied the files above this shouldn't be necessary),
Any time you get
Missing (or bad) header file
check to see you copied the *.h files to mingw64\include and/or add the include folder to the PATH. Use cabal install -v3 to get verbose error messages if the problem persists.
If you get something like
cairo-0.13.1.0: include-dirs: /mingw64/include/freetype2 is a relative path
which makes no sense (as there is nothing for it to be relative to). You can
make paths relative to the package database itself by using ${pkgroot}. (use
--force to override)
try --ghc-pkg-options="--force" (as mentioned at https://github.com/gtk2hs/gtk2hs/issues/139).
Get SDL. Otherwise you'll get
configure: error: *** SDL not found! Get SDL from www.libsdl.org.
If you already installed it, check it's in the path. If problem remains,
please send a mail to the address that appears in ./configure --version
indicating your platform, the version of configure script and the problem.
Failed to install SDL-0.6.5.1
Follow the instructions in (2) to get sdl/sdl2 libraries. (See instructions here Installing SDL on Windows for Haskell (GHC).)
The new version helm-0.7.1 requires sdl2, but there are other dependency issues with helm-0.7.1 as of writing. Download SDL from http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/ (direct download link to newest version as of writing http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/mingw-w64-x86_64-SDL-1.2.15-7-any.pkg.tar.xz.sig/download), unzip. "cabal install sdl" gives
* Missing (or bad) header file: SDL/SDL.h
* Missing C library: SDL
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
so we specify where the dirs are (change the name depending on where you extracted sdl to)
cabal install sdl --extra-include-dirs=C:/PF/sdl\include --extra-lib-dirs=C:/sdl/lib
If you got SDL2 (http://libsdl.org/download-2.0.php) (for a newer version of Helm): there is a fatal bug that hasn't been fixed in the release version. (If you don't fix it, cabal install -v3 things which depends on it will give error
winapifamily.h: No such file or directory
("winapifamily.h: No such file or directory" when compiling SDL in Code::Blocks) Download https://hg.libsdl.org/SDL/raw-file/e217ed463f25/include/SDL_platform.h, replace the file in the include folder and in C:/PF/msys64/mingw64/include/SDL2.
Download gtk2hs from http://code.haskell.org/gtk2hs and run
the following
cd gtk2hs/tools
cabal install
cd ../glib
cabal install
cd ../gio
cabal install
cd ../pango
cabal install --ghc-pkg-options="--force"
(Maybe you have already installed glib and gio from before? I did this step because normal install of Pango caused an error for me (https://github.com/gtk2hs/gtk2hs/issues/110)
pango-0.13.1.0: include-dirs: /mingw64/include/freetype2 is a relative path
which makes no sense (as there is nothing for it to be relative to). You can
make paths relative to the package database itself by using ${pkgroot}. (use
--force to override)
Once the Helm developers get things updated you should be able to do "cabal install helm" but right now there seem to be dependency issues. For me, cabal automatically tries to install helm-0.4 (probably because 0.4 didn't give upper bounds on dependencies, while newer versions do. You could try "cabal unpack"ing and deleting the upper bounds...). Then
cabal unpack helm-0.4
Installing gives an error because "pure" got moved to Prelude. Open helm-0.4\src\FRP\Helm\Automaton.hs and change line 17:
import Prelude hiding (id, (.), pure)
Now
cabal install
Try to compile and run a program using Helm
(This is 0.4 - look on the website for a newer sample if you tried a newer Helm)
import FRP.Helm
import qualified FRP.Helm.Window as Window
render :: (Int, Int) -> Element
render (w, h) = collage w h [filled red $ rect (fromIntegral w) (fromIntegral h)]
main :: IO ()
main = run $ fmap (fmap render) Window.dimensions
If you get an error about a missing .dll (sdl.dll), find it in a bin/ folder and add the folder to your PATH (or copy it to somewhere on your path).