I'm such a beginner on OpenWrt and Makefiles, trying to demonstrate "Helloworld" example of creating a package but at the package feed update step, from command ./scripts/feeds update mypackages I get this error
Updating feed 'mypackages' from '/home/onur/Desktop/OpenWRT/openwrt/mypackages' ...
Create index file './feeds/mypackages.index'
/home/onur/Desktop/OpenWRT/openwrt/feeds/mypackages.tmp/info/.files-packageinfo.mk:1: *** target pattern contains no '%'. Stop.
I have src-link mypackages /home/onur/Desktop/OpenWRT/openwrt/mypackages in my feeds.conf, "helloworld" C program compiled on /openwrt/helloworld directory and below is my Makefile:
include $(TOPDIR)/rules.mk
# Name, version and release number
# The name and version of your package are used to define the variable to point to the build directory of your package: $(PKG_BUILD_DIR)
PKG_NAME:=helloworld
PKG_VERSION:=1.0
PKG_RELEASE:=1
# Source settings (i.e. where to find the source codes)
# This is a custom variable, used below
SOURCE_DIR:=/home/onur/Desktop/OpenWRT/openwrt/helloworld
include $(INCLUDE_DIR)/package.mk
# Package definition; instructs on how and where our package will appear in the overall configuration menu ('make menuconfig')
define Package/helloworld
SECTION:=examples
CATEGORY:=Examples
TITLE:=Hello, World!
endef
# Package description; a more verbose description on what our package does
define Package/helloworld/description
A simple "Hello, world!" -application.
endef
# Package preparation instructions; create the build directory and copy the source code.
# The last command is necessary to ensure our preparation instructions remain compatible with the patching system.
define Build/Prepare
mkdir -p $(PKG_BUILD_DIR)
cp $(SOURCE_DIR)/* $(PKG_BUILD_DIR)
$(Build/Patch)
endef
# Package build instructions; invoke the target-specific compiler to first compile the source file, and then to link the file into the final executable
define Build/Compile
$(MAKE) -C $(PKG_BUILD_DIR) \
CXX="$(TARGET_CROSS)g++"
endef
# Package install instructions; create a directory inside the package to hold our executable, and then copy the executable we built previously into the folder
define Package/helloworld/install
$(INSTALL_DIR) $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/helloworld $(1)/usr/bin
endef
# This command is always the last, it uses the definitions and variables we give above in order to get the job done
$(eval $(call BuildPackage,helloworld))
I know I may have mistake on cross-compile part but I don't think that's the issue that I'm having right now.
When I try to make this Makefile, I get that error.
Makefile:13: /package.mk: No such file or directory
make: *** No rule to make target '/package.mk'. Stop.
I can't find any problem like this anywhere. Why it can't even find "package.mk" file.
My directory structure is like, Top directory is Desktop/OpenWrt/openwrt and this Makefile is in Desktop/OpenWrt/openwrt/mypackage folder. I'm on Ubuntu 20.04
I found solution to my question on OpenWrt Forum. Here is the link of thread
Related
I am inexperienced with make, and wanted to replicate a build structure provided by some third-party SDK and adapt it to my own compiler and project.
The thing is that I found that some rules are generated using the makefile as prerequisite, something like:
...
$(eval $(1): Makefile | $(dir $(1)).) \
...
or
$(OUTPUT_DIRECTORY)/%.inc: Makefile | $(OUTPUT_DIRECTORY)
$(info Generating $#)
$(NO_ECHO)$(call dump, $(call target_specific, INC_PATHS, $*)) > $#
Originally, their makefile is Capitalized (Makefile) and the one I am working on is lowercase (makefile). Anyway, When I try my current changes, this error appears:
*** No rule to make target 'Makefile', needed by '...'
I supposed that was due to the capitalization, so changed to lowercase in both places and tried again, but this time the error is that the makefile is treated as a C file (This is my guess...)
"makefile", line 1: error #171: expected a declaration
-include makefile.local
^
"makefile", line 67: error #8: missing closing quote
${CG_TOOL_ROOT}/include"
^
"makefile", line 99: error #10: "#" not expected here
.SUFFIXES: # ignore built-in rules
^
"makefile", line 100: error #10: "#" not expected here
%.d: # don't try to make .d files
^
"makefile", line 100: error #8: missing closing quote
%.d: # don't try to make .d files
What could be the issue here? Is there something I am missing?
EDIT 1:
These are the files I am trying to use.
Nordic provides these as part of their SDK for development using arm-gcc for ARM platforms. There is a Makefile per project and there is a Makefile.common included in the main Makefile.
Makefile
Makefile.common
On the other side, I am trying to understand and replicate the same but for another proprietary compiler with different options and syntax (TI's cl430 for MSP430 platforms). From the original Makefile.common I removed some references to the gnu-arm suite and replace it with the proper compiling tools. In the makefile I also tried to replicate the same structure of the original but using my sources and options.
makefile
makefile.common
Just to make it clear, originals are capitalized, mine are lowercase.
EDIT 2:
After running make --debug --print-data-base I found this:
The error appears in the first attempt to build a file:
Updating goal targets....
File 'default' does not exist.
File 'test_project' does not exist.
File '_build/test_project.out' does not exist.
File '_build/test_project/<SOURCE_FILE>.c.o' does not exist.
Must remake target '_build/test_project/<SOURCE_FILE>.c.o'.
Building file: "makefile"
Invoking: MSP430 Compiler
"cl430" -vmspx --use_hw_mpy=F5 <... a lot of options ...> --obj_directory="./_build" "makefile"
"makefile", line 1: error #171: expected a declaration
-include makefile.local
^
[ ... more errors ...]
However, from the debug and DB information, I found that the source file rule indeed requires makefile, and that makefile is not a target, but somehow it is trying to build it:
# Not a target:
makefile:
# Implicit rule search has been done.
# Last modified 2020-02-25 11:43:33.609423171
# File has been updated.
# Successfully updated.
_build/test_project/<SOURCE_FILE>.c.o: makefile | _build/test_project/.
# Implicit rule search has been done.
# Implicit/static pattern stem: '_build/test_project/<SOURCE_FILE>'
# Modification time never checked.
# File has been updated.
# Failed to be updated.
# automatic
# # := _build/test_project/<SOURCE_FILE>.c.o
# automatic
# % :=
# automatic
# * := _build/test_project/<SOURCE_FILE>
# automatic
# + := makefile
# automatic
# | := _build/test_project/.
# automatic
# < := makefile
# automatic
# ^ := makefile
# automatic
# ? := makefile
# variable set hash-table stats:
# Load=8/32=25%, Rehash=0, Collisions=1/30=3%
# recipe to execute (from 'makefile.common', line 192):
#echo 'Building file: "$<"'
#echo 'Invoking: MSP430 Compiler'
"${CG_TOOL_ROOT}/bin/cl430" -vmspx --use_hw_mpy=F5 <... a lot of options ...> "$(shell echo $<)"
#echo 'Finished building: "$<"'
#echo ' '
That dependency on Makefile is to make sure that it rebuilds when Makefile has been changed. For example, if you change CFLAGS in Makefile or a rule to compile or link, this dependency triggers a rebuild (provided object files depend on Makefile, as they should). Without dependency on Makefile those changes won't cause a rebuild.
The error messages in the form of "makefile", line 1: error #171: expected a declaration suggest that makefile is passed as a source file to a C compiler that produces the error message.
The rules most likely do $(filter-out Makefile,$^). You need to replace all occurrences of Makefile to makefile.
*** No rule to make target 'Makefile', needed by '...' means that Makefile is still a prerequisite of some targets. You can find what those targets are by passing --debug --print-data-base command line options to make.
I wrote my own openwrt package for my script and the compilation stage I put it in the package file as this path openwrt / feeds / package / is that the path is correct or not?
or if I have is for the compilation error:
make[1]: *** No rule to make target `package/test/compile'. Stop.
make: *** [package/test/compile] Error 2
THis my Makefile:
include $(TOPDIR)/rules.mk
include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=test
PKG_VERSION:=1.0
PKG_RELEASE:=1
PKG_BUILD_DIR := $(BUILD_DIR)/$(PKG_NAME)
DEPENDS:= +nmap +python
include $(INCLUDE_DIR)/package.mk
define Package/test
SECTION:=secure
CATEGORY:=Monitoring
TITLE:=test
define Package/test/description
test tis is my first package
endef
define Build/Prepare
mkdir -p $(PKG_BUILD_DIR)
$(CP) ./src/* $(PKG_BUILD_DIR)/
endef
define Package/test/install
$(INSTALL_DIR) $(1)/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/test $(1)/bin/
endef
$(eval $(call BuildPackage,test))
I need help please.
thanks.
You don't really have to put your source code anywhere in the /openwrt/ folder. It can be placed, let's say, in /Documents/[name] folder. However it is important that you put your OpenWRT-specific Makefile in the /openwrt/ tree. I am not sure if putting your Makefile in /openwrt/feeds/package is correct but I put my Makefiles in /openwrt/package/[name] folder which works fine. Your source code will be automatically copied by the toolchain to the same folder anyway.
Note: if you place your source code somewhere on your system (for example, in the Documents folder) you have to specify the path to it in your Makefile as follows: PKG_SOURCE_URL:=file://$(TOPDIR)/../Documents/[name]
Your make[1] errors are basically telling you that the toolchain could not find the Makefile. Try putting Makefile in /openwrt/package/[name].
http://puu.sh/7OiDL.png
Ok so what does export: StackImplementation.o do? Like where does it export that to?
Also, what is gcc -l doing? I googled it and it says "gcc -l links with a library file". What's linking to the library file?
Lastly, what does "substitute a print command of your choice for lpr below" mean? What's lpr do? and what's clean: rm -f *.o?
The export is the name of a phony target. You can say
% make export
And make will build the its dependencies. There is no action specifying how to convert the dependencies into a file called export, and in the absence of an implicit rule, the make will stop after building the dependencies.
The -I to gcc is adding a path to search for include files. You are confusing it with the -l option which specifies the name of a library to link (a pre-built collection of object files from which unresolved symbols can be satisfied).
The lpr command sends a file to the default line printer. Again, print is a phony target; doing
% make print
sends the source file to the printer.
Most makefiles include a clean rule to delete generated files. It is necessary when the dependencies are not properly specified, and a change to a source file does not cause the target to be built. The rm command is short for remove; it deletes files. If you do
% make clean
it will force-delete all files that end with .o.
Most of these targets are phony, and will not work correctly if there happen to be files with those names that are newer than their dependencies (if any). Most makes allow you to specify which targets are phony by listing them as dependencies of a super phony .PHONY target. Make will then ignore the filesystem, and will always apply the rules.
export:
this is a target named "export" and is the first target in the makefile so it will get called by default if no target is specified on the command line. Not clear to me why it is called "export" but that's the name somebody chose for it
export: StackImplementation.o
this says that export depends on StackImplementation.o so it will invoke the target StackImplementation.o when export is invoked
StackImplementation.o: StackImplementation.c ...
StackImplementaiton.o depends on the source file StackImplementation.c and the include files listed. This will run gcc which has the flag -I../Include which tells gcc to include .h files in adjacent directory "Include"
# substitute...
this is a comment indicating to change the print command lpr to some other print command if you want to
clean:
this is a common target that will delete object files with the -f option, forcing remove even if write permission is not set
1) lpr submits files for printing. Files named on the command line are sent to the named printer
(or the default destination if no destination is specified). If no files are listed on the com‐
mand-line, lpr reads the print file from the standard input.
for more information about "lpr " use user manual of linux.
2)gcc -l link external library to your program if any dependency .
example::
gcc hello.c -o hello -lpthread -ldrm -ldrm_omap
in Make file::
clean:
rm -rf *.o
here clean is a rule of make and when we call make clean then it will invoke rm -rf *.o to remove all object files.
I have a rooted Sony reader PRS900, running an OEM linux kernel 2.6.23, and I can run arbitrary bash/sh scripts from the SD memory card drive on it.
I want to compile and execute C programs ... but am having dynamic linker problems.
I first tried loading gcc for arm (slackware 14's) on the SD card, but even when using LD_LIBRARY_PATH, the sony will fail to "find" most newer elf .so libraries, although newer programs which use old libraries do in fact run properly. ( I can run slackware-14's "readelf" just fine. but not ar, or gcc...) If I try to upgrade /lib/ld-linux.so.3, I get a "kernel too old" error message.
I then tried an old slackware 10 version of gcc, and although that solves the elf library "finding" problem -- I then get an "illegal instruction" error when running programs.
So -- I need to make a gcc cross compiler on my x86 for the proper ARM processor and then use it to recompile gcc for the sony.
But I don't know what legacy version of binutils I must use since it assembles and links to ELF format that either works or breaks on the sony.
The Sony is running an arm6 compatible MX31 EBX5016 processor.
and some relevant OEM file names on the sony are:
/lib/ld-2.5.so
/lib/ld-linux.so.3 -> ld-2.5.s
/lib/libc-2.5.so
/lib/libgcc_s.so.1
I know, from the kernel, that gcc-4.2.0 was used.
I would prefer to use the newest version of gcc which will work with whatever legacy binutils package I need to install.
How do I figure out which version of binutils that I need, and what options I have for gcc?
Thanks!
You can find the toolchain Sony used over at their Source Code Distribution Service site:
http://www.sony.net/Products/Linux/Audio/PRS-900.html
It seems sourceryg++-4.2-28armeabi.src.rpm is the compiler.
I would not recommend running the compiler on the device itself; it will be very slow.
Regarding the "Illegal instruction" issue, it's possible that your compiler is generating too new instructions, and passing -march=armv6 might just solve it.
Sony is using a kernel put out by motavista linux; According to montavista, the compiler for that kernel was made with binutils 2.17. I wasn't able to find any way to figure out which binutils originally developed with which version of GCC from the gnu project itself. Even the repository upload dates vary inconsistently... but I did find which binutils montavista was developed with.
The minimum version of a working cross compiler from stock GCC source code that I was able to make, came from gcc-4.2.0 with binutils 2.19.1 and glibc-2.5 using glibc-ports-2.5 for the arm processor/linux extensions.
The rest of this answer details building that cross compiler from scratch, as a reference for other people wanting to build a linux cross compiler for arm with the gnu c library included; eg: gcc with eabi and glibc for linux: arm-linux-gnueabi- tool.
It's a totally non-trivial problem, and I hope my notes are useful to others.
The sony reader PRS900 uses an EABI compiler to make the kernel, and it is also configured as little endian.
Binutils was switching from arm eabi-V4 to eabi-V5 at the time, and Sony's PRS-900 /lib/ld-* appears to expect the eabi-5 flag to be set or else it gets confused. when linking with binutils, people can accidentally mix eabi 4 and 5 object files which causes most of the problems, because it will default back to eabi-version 4 for the link: so, the way to make sure that eabi 4 is never produced accidentally, is to edit the default header files for the gas (Gnu ASsmebler) so it always defaults to eabi-5 even when building the cross compiler libraries unless explicitly told to do otherwise.
eg: these two files in binutil:
gas/config/te-armeabi.h <--change EABI_VER4 to --> #define EABI_DEFAULT EF_ARM_EABI_VER5
gas/config/te-armlinuxeabi.h <--do same--> #define EABI_DEFAULT EF_ARM_EABI_VER5
It would in fact be easier to use the code-sourcery tools than to build a gcc toolchain,
from scratch (I'm going to test them to see if they work on kernel modules, too) -- but as I intend to upgrade to newer tools -- I needed to know how to do this from scratch.
Below: I've included a script which is more important for the notes it contains than for it's usability; eg: It is NOT intended to be run and is not automatic -- but rather, it's to be cut and pasted into a shell and used as a cheat sheet outlining the flags which work and the files which must be manipulated to circumvent bugs. It has comments which are meant to be read, and although imperfect -- a human reading error messages should be able to figure out the rest from the shell's error messages.
I could not get libmudflap, libgomp, or libssp to work in gcc -- no matter how I tried, so they are disabled in the GCC build because all three cause insoluble compiling problems; but other than that, this script shows what is needed to build a "C" cross compiler arm-linux-gnueabi- toolchain which will compile and link Sony PRS-900 binary executables that run without segfaults, or errors.
One note:
It does NOT build kernel modules with the correct CRC codes, and it seems that the kernel that sony releases on their website (see previous post) is slightly different than the one on my sony; although the dates are identical and I used the /proc/config.gz from my actual sony. I intend to open a separate thread to solve that problem... but at least one can build user space executables with this cross compiler with no problems.
#!/bin/false
# Do not run this script directly, until you have read and edited source
# files appropriately. It's not automated. vim is a text editor...
# This script creates a toolchain in a local directory (not root).
# I made it to build a gcc toolchain on a USB memory stick,
# mounted under /media/memory1 on slackware14.
#
# Needed source files:
#
# binutils-2.19.1.tar.bz2
# gcc-core-4.2.0.tar.bz2
# linux-2.6.23_091126.tgz
# glibc-2.5.tar.bz2
# glibc-ports-2.5.tar.bz2
#
# and from the sony PRS-900, itself, you need file: /proc/config.gz
# To guarantee the kernel is compiled the same.
# First make a local script to set paths for the toolchain once it it built
# --------------
echo -e "\
#!--/bin/bash-- # but must run as . setArmEnvironment.rc \n\
# There are two kinds of binaries for cross compilation, the tool binaries\n\
# and libraries, and the target headers, libraries, etc.\n\
export CROSSROOT="\$PWD/.local"\n\
export TARGETROOT="\$PWD/.target"\n\
export PATH="\$PATH:\$CROSSROOT/bin"\n\
export LD_CONFIG_PATH="\$CROSSROOT/lib:\$LD_CONFIG_PATH"\n\
" > setArmEnvironment.rc
# ----------
# Next:
# Create the local binary and header directories for the cross compiler toolchain
# .local is the buld machines' local tools for arm development
# This is for the binaries for the machine doing the cross compiling.
mkdir .local
cd .local
ln -s . usr
ln -s . local
mkdir include
mkdir lib
mkdir bin
ln -s include sys-linux
cd ..
# Target is for the host tools, headers, etc. it is a pure ARM directory.
# Everthing here is potentially installable on the sony itself.
# And is what would appear on the SONY PRS-900 if it had a toolchain.
mkdir .target
cd .target
ln -s . usr
ln -s . local
mkdir include
mkdir lib
mkdir bin
ln -s include sys-linux
cd ..
# Now, we need to set the paths so that as we make build tools, we can
# use them from the shell we are in.
. setArmEnvironment.rc
# FIRST! ----------------------------------------------------------------------
# Problem: GCC supposedly needs some g-libc header files for proper target code
# generation...
# but they don't really exist until compiled -- so chicken-egg-rooster prob !
# Which to make first...
#
# Solve it by installing headers from uncompiled packages, using a broken gcc/binutils
# then, re-build and re-install proper header files -- re-build proper gcc... etc.
# build a broken binutils package.
tar -xf /tmp/binutils-2.19.1.tar.bz2
mkdir build.binutils.eabi
cd build.binutils.eabi
../binutils-2.19.1/configure --target=arm-eabi --prefix=$CROSSROOT
# Make with flags to prevent warning creep on newer GCC's compiling older code.
make CFLAGS="-Os -w"
make install
cd ..
# build a broken gcc core.
tar -xf /tmp/gcc-core-4.2.0.tar.bz2
mkdir build.gcc.eabi
cd build.gcc.eabi
../gcc-4.2.0/configure --target=arm-eabi --prefix=$CROSSROOT --enable-multilib --disable-libssp
make CFLAGS="-Os -w"
make install
cd ..
# Install kernel headers using first pass (broken) cross-compiler -------------
tar -xf /tmp/linux-2.6.23_091126.tgz
gzip -d config.gz
cp config linux-2.6.23_091126/.config
cd linux-2.6.23_091126
# The makefile is a little broken for use on slackware 14...
# edit so that:
# CROSS_COMPILE ?= arm-eabi-
# and make the two implicit rules explicit:
# eg: lines 425 and 1476 contain rules that need to be broken into two rules each:
# Here's a patch file to do it automatically -- paste as one quoted unit to shell:
# ******************** START ECHO DIFF COPY/PASTE
echo '192c192
< CROSS_COMPILE ?= /opt/timesys/toolchains/armv6j-linux/bin/armv6j-linux-
---
> CROSS_COMPILE ?= arm-eabi-
422c422
< config %config: scripts_basic outputmakefile FORCE
---
> %config: scripts_basic outputmakefile FORCE
424a425,428
> config: scripts_basic outputmakefile FORCE
> $(Q)mkdir -p include/linux include/config
> $(Q)$(MAKE) $(build)=scripts/kconfig $#
>
1472c1476,1479
< / %/: prepare scripts FORCE
---
> %/: prepare scripts FORCE
> $(Q)$(MAKE) KBUILD_MODULES=$(if $(CONFIG_MODULES),1) \
> $(build)=$(build-dir)
> /: prepare scripts FORCE
1475c1482
< %.ko: prepare scripts FORCE
---
> %%.ko: prepare scripts FORCE' > Makefile.diff
# ******************** END ECHO DIFF COPY/PASTE
# now apply the patch to the Makefile
patch Makefile Makefile.diff
# You might also need to edit
# vim linux scripts/unidef.c and search all instances of getline, replacing it with _getline to avoid stdio.h overloading conflict.
# This is not always necessary... but if you have the problem... that's the solution.
make ARCH=arm INSTALL_HDR_PATH=$TARGETROOT headers_install
cd ..
# DONE installing kernel header files somewhat sanitized...
------------------------ GLibc, headers install
## Create aliases for binutils so I don't need to fight with glibc...
cd .local/bin
for i in `ls arm-eabi-*`; do ln -s $i arm-linux${i##arm-eabi} ; done
cd ../..
# Now we need to build glibc-2.5 with the arm port (glibc-ports-2.5.tar.gz)
tar -xzf glibc-2.5.tar.gz
cd glibc-2.5
tar -xzf ../glibc-ports-2.5.tar.gz
mv glibc-ports-2.5 ports
# Steal configuration for arm from other processors... probably not needed.
cp sysdeps/wordsize-32/bits/wordsize.h bits # 32bits
cp sysdeps/i386/bits/endian.h bits # little endian
cd ..
# For the first pass, just make enough of libc to install the header files.
mkdir build.glibc.eabi
#bash # Enter a new shell, because path needs to be forced.
# CAUTION: You must not do this as superuser, or with write priveleges to
# the system directores, as there are bugs in the GLIBC install that
# will try to put them there even though they don't belong there in a cross
# compiler..!
(
cd build.glibc.eabi
export LD_LIBRARY_PATH=""
export PATH=$CROSSROOT/bin:$PATH
echo "libc_cv_forced_unwind=yes" > config.cache
echo "libc_cv_c_cleanup=yes" >> config.cache
echo "libc_cv_arm_tls=yes" >> config.cache # For posix threads, but maybe not.
../glibc-2.5/configure --with-binutils=$CROSSROOT/arm-eabi/bin --build=i686-linux --host=arm-linux --prefix=/usr --enable-kernel=2.6.23 --with-headers=$TARGETROOT/include --enable-add-ons --disable-profile --config-cache --disable-sanity-checks --with-tls --with-__thread
# Caution, this install will attempt to install to both --prefix=/usr AND install_root.
# Because any directories where actual compilation is unfinished will
# not make install_root= correctly, but default back to prefix.
# Therefore,
# Do not allow writes to local system directories, by not installing as root!
# ... AND ...
# You must run make install_headers twice so everything does end up in $TARGETROOT
make -k install-headers install_root=$TARGETROOT
make -k install-headers install_root=$TARGETROOT
# Manually install two files, ... or GCC won't build. Three if you want it all.
# Glibc has a *REAAAALY* crappy installer script ...
cp bits/stdio_lim.h $TARGETROOT/include/bits
touch $TARGETROOT/include/gnu/stubs.h
cp nptl/sysdeps/pthread/pthread.h $TARGETROOT/include
# Long-double is messed up ... I ran into this. :)
( cd $TARGETROOT/include/bits
sed '/ifndef.*NO_LONG_DOUBLE/,/#endif/d' < mathdef.h > mathdef.h.new
mv mathdef.h.new mathdef.h
)
# LIB-C woes.
# We don't have the core files made yet, but generally, linking for arm needs:
# ... elf-init.o crt1.o crti.o crtbegin.o [-L] [user.o's] [gcc lb] [C lb] crtend.o crtn.o
# Unfortunately, GCC uses these during configuration tests and to make libgcc.o
# so we need them NOW, even if they are a little wrong, to make gcc.
# What they are:
# crt1.o -- from glibc's Start.S --calls libc's __libc_csu_init, __libc_csu_fini
# crti.o -- gcc's default version is no good; but libc's is. defines prolog _init
# crtn.o -- ... ; defines function epilog _fini
# crtbegin.o and crtend.o are supplied by gcc, for constructors/destructors.
# elf-init.o -- I don't remember what it is, but it has fn's that gcc needs.
#
# so, we need to build the crt files -- and only them... as the rest can't be
# done yet. So we 'make' the crt's subdirectory.
make CFLAGS="-Os -w" ARCH=arm cross-compiling=yes csub/subdir_lib
# Manually install them in a place where the linker will find them...
cp csu/crt*.o $TARGETROOT/lib
# elf-init.o is only needed during the build of GCC. It should be removed
# after the new gcc is made, or if it causes errors when gcc is made for
# redundant symbols.
cp csu/elf-init.o $TARGETROOT/lib
) # finished with bash subtask. restore environment to normal.
# The .local tools we built previously are now basically useless
# I'll just move them, although you might want to remove them...
mv .local .local.eabi
# ****************************************************************************
# ----------------------------------------------------------------------------
# Build actual tools
# We must build gcc.linux.gnueabi in order for glibc programs to compile right...
# ----------------------------------------------------------------------------
# Create a clean .local directory
mkdir .local
cd .local
ln -s . usr
ln -s . local
mkdir include
mkdir lib
mkdir bin
ln -s include sys-linux
cd ..
# Rebuild the toolchain with the basic headers we just installed.
# First do bintools
# Be sure to Change the DEFAULT_EABI to version 5 before compiling gas.
mkdir build.binutils2.19.1.linux.gnueabi
cd build.binutils2.19.1.linux.gnueabi
../binutils-2.19.1/configure --target=arm-linux-gnueabi --prefix=$CROSSROOT --with-sysroot=$TARGETROOT
# Make with flags to prevent warning creep on newer GCC's compiling older code.
make CFLAGS="-O2 -w"
make install
cd ..
# !!!! Now for GCC.
mkdir build.gcc.linux.gnueabi
cd build.gcc.linux.gnueabi
../gcc-4.2.0/configure --target=arm-linux-gnueabi --prefix=$CROSSROOT --enable-multilib --disable-libssp --enable-shared --disable-libgomp --disable-werror --disable-libmudflap --with-sysroot=$TARGETROOT
make -j2
make install
cd ..
# Create the specs file for editing GCC's configuration if we want to...
arm-linux-gnueabi-gcc -dumpspecs > .local/arm-linux-gnueabi/lib/specs
# Edit the specs file, and make *startfile command read:
#
# %{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}} elf-init.o%s crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}
vim .local/arm-linux-gnueabi/lib/specs
# This edit will cause GCC to link the elf-init.o crti.o crt1.o crtn.o files (happily) from $TARGETROOT/lib where a user can easily install them.
# There are a few abused/problem header files... so fix them!
vim glibc-2.5/posix/regex_internal.h # line 393, changed static int to
#static reg_errcode_t build_wcs_upper_buffer (re_string_t *pstr) internal_function;
vim .target/include/asm/unistd.h # find line 410, comment it out...
# And do a softlink to fake out an abused header...
ln -s hwcap.h .target/include/asm/procinfo.h
# Now we can finally build a true libc...
mkdir build.glibc.gnueabi
( # Enter a new shell, because path needs to be forced.
rm -rf build.glibc.gnueabi/*
cd build.glibc.gnueabi
# GLibc errors out if it thinks LD_LIBRARY_PATH is set wrong, even if it's not.
# So disable it temporarily.
export LD_LIBRARY_PATH=""
echo "libc_cv_forced_unwind=yes" > config.cache # No crt1.o exists, yet...force
echo "libc_cv_ctors_header=yes" >> config.cache # constructor headers, yes?
echo "libc_cv_c_cleanup=yes" >> config.cache
echo "cross_compiling=yes" >> config.cache
echo "install_root=$TARGETROOT" > configparms # Where to really install target
export CFLAGS="-fgnu89-inline -D__OPTIMIZE__ -O2 "
../glibc-2.5/configure --build=i686 --host=arm-linux-gnueabi --prefix=/ --enable-kernel=2.6.23 --with-headers=$TARGETROOT/include --enable-add-ons --disable-profile --with-tls --with-__thread --cache-file=config.cache
make
make install-headers install_root=$TARGETROOT
make localedata/install-locales install_root=$TARGETROOT
) # End of subshell
EDIT ===================
The apr-1 is the apache portable runtime, which I downloaded and compiled myself to create the shared library (so its not made by cmake). I need to link against this library after I run CPack on the target system.
My development project directory:
read_config/bin
/libs
/include
/src
/build
For my CMakeLists.txt, everything installs ok, but now I have a linking problem, as it cannot find the new location of the library.
I have removed the LINK_DIRECTORIES(${PROJECT_SOURCE_DIR}/libs) as I don't need this now, as I am using the FIND_LIBRARY.
And added the following:
# Find the library in the libs folder
FIND_LIBRARY(APR_LIBS NAMES "apr-1" PATHS ${PROJECT_SOURCE_DIR}/libs)
# Print out the path to see if its correct
MESSAGE(${APR_LIBS})
# Link the library with the executable
TARGET_LINK_LIBRARIES(cfg ${APR_LIBS})
# Install the libs folder
INSTALL(DIRECTORY ${PROJECT_SOURCE_DIR}/libs/
DESTINATION libs)
# Install the executable in the bin folder
INSTALL(TARGETS cfg
RUNTIME DESTINATION bin)
Everything installs ok, but when I check the executable to see what libraries it links against it cannot find the apr-1 as it looks in the wrong place.
libapr-1.so.0 => not found
This is because I have extracted the installation package to a new location which is different to where it was compiled from. From the compiled directory I get this, which runs ok:
libapr-1.so.0 => /home/devel/projects/read_config/libs/libapr-1.so.0 (0xf7746000)
I after I install I have this directory structure on the target installation machine, so the executable will link with the new libs/apr-1 library:
target directory/
/bin
/libs/apr-1
Many thanks for any further suggestions,
========================================
gcc (GCC) 4.7.2
cmake version 2.8.9
Fedora 17
Hello,
I am getting in the following error:
CMake Error at src/CMakeLists.txt:14 (INSTALL):
install TARGETS given target "apr-1" which does not exist in this
directory.
I have the following directory:
read_config/
/build - out of source build
/CMakeLists.txt
/include - apr include files
/libs - apr libraries
/src - project source files *.h *.c CMakeLists.txt
In my root CMakeLists.txt I have the following:
# Name of project and compiler to use
PROJECT(read_cfg C)
# Set compiler flags
IF(CMAKE_COMPILER_IS_GNUCC)
MESSAGE(STATUS "COMPILER IS GNUCC")
SET(CMAKE_C_FLAGS "-Wall -Wextra -m32 -Wunreachable-code -ggdb -O0 -D_DEBUG -D_LARGEFILE64_SOURCE")
ENDIF(CMAKE_COMPILER_IS_GNUCC)
# Where the include files can be found
INCLUDE_DIRECTORIES(${CMAKE_SOURCE_DIR}/read_config/include)
# Where the libraries can be found
LINK_DIRECTORIES(${CMAKE_SOURCE_DIR}/read_config/libs)
ADD_SUBDIRECTORY(src)
In my src directory I have the following CMakeLists.txt
# Create the executable and link the libraries into it
ADD_EXECUTABLE(cfg test_config.c)
# Place executable in bin directory
SET(EXECUTABLE_OUTPUT_PATH ${CMAKE_SOURCE_DIR}/bin)
# Add libraries
IF(CMAKE_COMPILER_IS_GNUCC)
MESSAGE(STATUS "Linking cfg library")
TARGET_LINK_LIBRARIES(cfg apr-1)
ENDIF(CMAKE_COMPILER_IS_GNUCC)
INSTALL(TARGETS cfg
RUNTIME
DESTINATION bin)
INSTALL(TARGETS apr-1
ARCHIVE
DESTINATION lib)
SET(CPACK_PACKAGE_NAME "rd_cfg")
SET(CPACK_PACKAGE_VENDOR "sun.com")
SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY "rd_cfg - CPack read_config installation")
SET(CPACK_PACKAGE_VERSION "1.0.0")
SET(CPACK_PACKAGE_VERSION_MAJOR "1")
SET(CPACK_PACKAGE_VERSION_MINOR "0")
SET(CPACK_PACKAGE_VERSION_PATCH "0")
SET(CPACK_PACKAGE_INSTALL_DIRECTORY "Read_config_install_dir")
INCLUDE(CPack)
The problem is this line here:
INSTALL(TARGETS apr-1
ARCHIVE
DESTINATION lib)
I have tried doing the following
INSTALL(TARGETS ${CMAKE_SOURCE_DIR}/libs/apr-1
ARCHIVE
DESTINATION lib)
But it still fails to find the library.
And also using the path like this:
INSTALL(TARGETS src/libs
ARCHIVE
DESTINATION lib)
I would like to be able to just put the directory there like this so I don't have to specifiy each library, but just the directory like this:
INSTALL(TARGETS ${CMAKE_SOURCE_DIR}/libs
ARCHIVE
DESTINATION lib)
So it can find all the libraries in that directory. I have about 5 of them.
Many thanks for any suggestions,
The error seems to be a result of calling install in a different CMakeLists.txt to that in which apr-1 is defined via add_library.
I guess you're doing add_library(apr-1 ...) in your root CMakeLists.txt, which means that's where you need to call install(TARGETS apr-1 ARCHIVE DESTINATION lib).
Note that the error message "...does not exist in this directory." is not referring to actual directories in the filesystem sense, but rather the notional directories which come about via add_subdirectory commands.
Edit
In light of your comments, it seems that the issue is that apr-1 is not an actual CMake target, but rather just a library.
In this case, the install command cannot be the TARGETS version, it would have to be install(FILES...) or install(DIRECTORY...). This would probably mean you'd have to locate the library using e.g. find_library in order to get a full path.
Further Edit
This further problem is as a result of not setting the correct RPATH flags. You need to add the following lines to your src/CMakeLists.txt before the ADD_EXECUTABLE call:
SET(CMAKE_SKIP_BUILD_RPATH FALSE)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/libs")
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
LIST(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES "${CMAKE_INSTALL_PREFIX}/libs" isSystemDir)
IF("${isSystemDir}" STREQUAL "-1")
SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/libs")
ENDIF("${isSystemDir}" STREQUAL "-1")
For a full explanation on these CMake variables, see the CMake Wiki on RPATH handling
try adding this to your CMakeLists.txt
set(CMAKE_INSTALL_RPATH $LIBRARY_OUTPUT_PATH)