I have 4 files in different directories.
1. /home/Linux/NXP/XYZ/Embedded/Read/read.c
2. /home/Linux/NXP/XYZ/Embedded/main/mainfun.c
3. /home/Linux/NXP/XYZ/Embedded/write/write.c
4. /home/Linux/NXP/XYZ/Embedded/config/config.c
and the .bb file is located at
"/home/Linux/NXP/yocto/jethro/yocto/source/meta-mylayer/recipes-app/mainfun/mainfun.bb"
From mainfun.c I am calling different functions, the definitions of which are present inside write.c, config.c, read.c.
I have only come across a single file compilation using yocto so can you please help how do I write the .bb file? How can I compile and generate "XYZ_app" executable?
Here I attached my .bb file which I have written but it's not working:
DESCRIPTION = "multiple file compilation"
PR = "r0"
LICENSE = "CLOSED"
SRC_URI += "file://home/Linux/NXP/XYZ/Embedded/ \
"
S = "${WORKDIR}"
do_compile() {
${CC} ${CFLAGS} ${LDFLAGS} --static -c ${WORKDIR}}/home/Linux/NXP/XYZ/Embedded/read/read.c
${CC} ${CFLAGS} ${LDFLAGS} --static -c ${WORKDIR}}/home/Linux/NXP/XYZ/Embedded/write/write.c
${CC} ${CFLAGS} ${LDFLAGS} --static -c ${WORKDIR}}/home/Linux/NXP/XYZ/Embedded/conf/conf.c
${CC} ${CFLAGS} ${LDFLAGS} --static -c ${WORKDIR}}/home/Linux/NXP/XYZ/Embedded/mainfun/mainfun.c
${CC} ${CFLAGS} ${LDFLAGS} --static ${WORKDIR} /home/Linux/NXP/XYZ/Embedded/Read/read.o /home/Linux/NXP/XYZ/Embedded/write/write.o /home/Linux/NXP/XYZ/Embedded/conf/conf.o /home/Linux/NXP/XYZ/Embedded/mainfun/mainfun.o -c XYZ_App
}
do_install() {
install -m 0755 -d ${D}${bindir}
install -m 0755 ${S}/XYZ_App ${D}${bindir}
}
The direct compilation of source files in a recipe is a testing/emergency solution at best. Whenever it comes to something even only slightly advanced, the correct way is to use a build system of any kind.
Those directly supported in OpenEmbedded include (amongst others)
Makefiles
Autotools
CMake
Here are examples for a couple of recipes for those systems: http://www.yoctoproject.org/docs/2.4/dev-manual/dev-manual.html#new-recipe-testing-examples
Properly packing the sources up also gives you a way to easily test the compilation and application without having to invoke the whole bitbake process. All of them have pros and cons, so you might want to dig a deep further. For a start into autotools, this seems to be a good thing:
https://developer.gnome.org/anjuta-build-tutorial/stable/create-autotools.html.en
An alternative is to look at GNU hello, and also the corresponding recipe.
Related
I have been working on a 32-bit operating system project written in C using GNU LD version 2.34 as the linker.
As part of the build process, I use the following command:
ld -m elf_i386 -nostdlib -T ld/loader.ld build/bootloader/loader.o build/bootloader/loader.elf -o loader_full.elf
When using GNU LD version 2.34, this command succeeds. However, when I use a version higher than this, I get the following error:
ld: cannot use executable file 'build/bootloader/loader.elf' as input to a link
If necessary, here is the full Makefile script:
CC_FLAGS = -g -m32 -ffreestanding -nostartfiles -nostdlib -fno-stack-protector
LD_FLAGS = -m elf_i386 -nostdlib
CC := gcc ${CC_FLAGS}
LD := ld ${LD_FLAGS}
BOOTLOADER_DRIVERS = kernel/drivers/disk/ata.c kernel/drivers/io/screen.c kernel/drivers/utils/mem.c kernel/drivers/utils/ports.c
raw: prep os-image.bin
convert_vmdk: os-image.vmdk
all: prep os-image.bin
ESFS_raw_write: ESFS_raw_write.c
gcc $^ -o $#
# run OS in QEMU
run:
qemu-system-i386 -drive format=raw,file=os-image.bin
# assemble boot sector
build/bootloader/boot_sect.bin: boot/boot_sect.asm
nasm $^ -f bin -o $#
# compile second stage bootloader
build/bootloader/loader_2.o build/drivers/*.o: boot/*.c ${BOOTLOADER_DRIVERS}
${CC} -c $^
mv loader.o build/bootloader/loader_2.o
mv *.o build/drivers/
# link object files into kernel loader
build/bootloader/loader.elf: build/bootloader/loader_2.o build/drivers/*.o
${LD} -T ld/loader.ld $^ -o $#
rm build/bootloader/loader_2.o
# assemble first stage bootloader
build/bootloader/loader.o: boot/loader.asm
nasm $^ -f elf -o $#
# link first and second stage bootloaders
build/bootloader/loader_full.elf: build/bootloader/loader.o build/bootloader/loader.elf
${LD} -T ld/loader.ld $^ -o $#
# make bootloader binary file
build/bootloader/loader.bin: build/bootloader/loader_full.elf
objcopy $^ -O binary $#
./scripts/pad_loader.sh
# clean up unnecessary files
# rm build/bootloader/*.o build/bootloader/*.elf build/drivers/*.o
build/kernel/interrupt.o: kernel/cpu/interrupt.asm
nasm $^ -f elf -o $#
# compile kernel & write to 10MB raw drive image
build/kernel/hdd.bin: kernel/drivers/*/*.c kernel/cpu/*.c kernel/libc/*.c build/kernel/interrupt.o kernel/*.c
${CC} $^ -o build/kernel/kernel.o -T ld/kernel.ld
./scripts/write_kernel_to_drive.sh
# concat 3 boot stages into os-image file
os-image.bin: build/bootloader/boot_sect.bin build/bootloader/loader.bin build/kernel/hdd.bin
cat $^ > $#
os-image.vmdk:
VBoxManage convertfromraw os-image.bin os-image.vmdk --format VMDK
VBoxManage internalcommands sethduuid /home/tim/Dev/OSDev/os-image.vmdk 6372c00a-a62e-4241-9a21-90fa4c22f019
# prepare directory structure for build process
prep:
mkdir -p build/bootloader
mkdir -p build/drivers
mkdir -p build/kernel
# clean up build files and os-image binary
clean:
-rm -rf build/
-rm *.bin *.vmdk
-rm ESFS_raw_write
The project is also on GitHub, so you can build it for yourself:
http://github.com/TimCve/OSDev.git
I have just come up with a similar problem.
It seems ld version GNU ld (GNU Binutils) 2.36.1 links the file into an executable format.
To fix it, add -r in your ld command to output a relocatable format file.
From the ld manual:
-r
--relocateable
Generate relocatable output--i.e., generate an output file that can in turn serve as input to ld. This is often called partial linking. As a side effect, in environments that support standard Unix magic numbers, this option also sets the output file's magic number to OMAGIC. If this option is not specified, an absolute file is produced. When linking C++ programs, this option will not resolve references to constructors; to do that, use -Ur. This option does the same thing as -i.
It's not that ld can't take ELF files as input. It's that it won't take executable files as input. The error is:
ld: cannot use executable file '...' as input to a link
See https://sourceware.org/bugzilla/show_bug.cgi?id=26223
Does it work to simply use chmod -x $# after building the .elf file?
In my (eclipse-based) multicore MCUXpresso project, I had to add this line to my post-build steps to modify a byte inside of the generated "*.o" file so the linker step which used that file wouldn't complain anymore. This happened after I updated to version 11.6 which includes the LD version mentioned previously. I originally found this on the forums for NXP MCUXpresso, but I assume it will work similarly for just about anyone:
dd if=/dev/zero of="${BuildArtifactFileName}.o" bs=1 seek=16 conv=notrunc count=2
NXP MCUXpresso fix
I'm trying to build and install my own gcc 4.7.2 in /usr/local to use in place of the gcc 4.4.6 in /usr. (This is on CentOS 6.3.)
gcc makes executables and dynamic libraries that dynamically link to its own dynamic libraries, e.g. libstdc++.so. How do I build and install gcc so that the generated binaries automatically get a linker -rpath option (-rpath /usr/local/lib64) that causes dynamic libraries in /usr/local/lib64 to be linked instead of those in /usr/lib64 or /lib64?
If it works properly, after I build an executable with the gcc without specifying "-Wl,-rpath=/usr/local/lib64", when I ldd the executable, it should show /usr/local/lib64/libstdc++.so.6 instead of /usr/lib64/libstdc++.so.6. Similarly for the libgcc_s.so.1.
I have tried different approaches, including specifying LDFLAGS_FOR_TARGET=-Wl,-rpath=/usr/local/lib64,-rpath=/usr/local/lib on the 'configure' command-line, but nothing worked.
If you don't want to export paths there's an alternative solution:
with your toolchain in the PATH:
gcc -dumpspecs > specsfile
edit specsfile and in the section link add your -rpath example:
*link:
%{!static:--eh-frame-hdr} -m %(link_emulation) %{shared:-shared} %{!shared: %{!static: %{rdynamic:-export-dynamic} -dynamic-linker %(dynamic_linker)} %{static:-static}} -rpath /usr/local/lib64
at this point you can test if it work with:
g++ -specs=specsfile test.cpp
readelf -d a.out |grep RPATH
if it work you can make it permanent (no need to pass -specs everytime)
strace -fF -o /tmp/g++.log g++ test.cpp
grep specs /tmp/g++.log
the grep should show the paths where gcc look for the default specs file.
The specs files are flexible enough to allow conditional linking depending on variables, example:
{!static: %{mabi=n32:-rpath-link %R/lib32:%R/usr/lib32} %{mabi=64:-rpath-link %R/lib64:%R/usr/lib64} %{mabi=32:-rpath-link %R/lib:%R/usr/lib}}
should use different and multiple paths depending on mabi (untested, yet), %R should be the sysroot path, can be changed with needed full path.
There's also a --with-specs= option gcc configure eventually to be used at build time, not clear to me yet how to use with the link section (working on it).
--with-specs="%{shared:-Wl,-rpath -Wl,$(DESTDIR)/lib}%{!shared:-Wl,-rpath -Wl,$(DESTDIR)/lib}"
It work, I used both shared and not !shared just for test, probably some smarter condition should be used, note that it isn't reported with -dumpspecs.
Reading through some thread of the gcc mailing list I had the impression specs aren't liked by everyone (but if I'm not wrong 4.9 add another option --with-extra-specs) instead preferred way to do such customizations appears to be configure.host, but I'm done and not looking into it, have fun! :-)
see also: gcc faq rpath
update above
I don't know if you can set a pre-defined rpath, probably if you can would be in the linker ld of binutils not in gcc/g++, but why would you do that?
Just export LD_LIBRARY_PATH at runtime and LD_RUN_PATH at build time
export LD_LIBRARY_PATH=/usr/local/lib64:$LD_LIBRARY_PATH
ldd a.out
ldd should show the paths you exported.
To quote a message given when a shared library is built with libtool:
If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following:
add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution
add LIBDIR to the `LD_RUN_PATH' environment variable during linking
use the `-Wl,--rpath -Wl,LIBDIR' linker flag
have your system administrator add LIBDIR to `/etc/ld.so.conf'
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
for completeness
the Makefile I used for testing the thing, all the configure options, environment variables (see boot ldflags) I tried didn't work, --enable-rpath included.
use with mkdir ~/gcc copy the Makefile below into ~/gcc then cd ~/gcc && make build-gcc
notice the options used are only for this test case, don't use as reference.
FETCH = aria2c --file-allocation=none -c -d dl
NICE = nice -n 19
PARALLEL = -j4
DESTDIR = $(HOME)/gcc/install
SRCDIR = $(HOME)/gcc/src
all:
# if more downloads are added just remove {dl,src}/*-my-stamp not the .bak
# the .bak should avoid to rebuild targets because of timestamp
touch_stamp = if [ -f $#.bak ]; then \
touch -r $#.bak $#; \
else \
touch $# $#.bak; \
fi
dl/dl-my-stamp:
$(FETCH) https://ftp.gnu.org/gnu/gcc/gcc-4.7.2/gcc-4.7.2.tar.bz2
$(FETCH) http://ftp.gnu.org/gnu/gmp/gmp-4.3.2.tar.bz2
$(FETCH) ftp://gcc.gnu.org/pub/gcc/infrastructure/mpc-0.8.1.tar.gz
$(FETCH) https://ftp.gnu.org/gnu/mpfr/mpfr-2.4.2.tar.bz2
$(FETCH) --check-certificate=false http://www.mirrorservice.org/sites/sourceware.org/pub/binutils/snapshots/binutils-2.24.51.tar.bz2 \
ftp://sourceware.org/pub/binutils/snapshots/binutils-2.24.51.tar.bz2
$(touch_stamp)
untar_dep = src/untar-my-stamp
src/untar-my-stamp: dl/dl-my-stamp
mkdir -p src
tar -C src -xjf dl/gcc-4.7.2.tar.bz2
tar -C src -xjf dl/gmp-4.3.2.tar.bz2
tar -C src -xzf dl/mpc-0.8.1.tar.gz
tar -C src -xjf dl/mpfr-2.4.2.tar.bz2
tar -C src -xjf dl/binutils-2.24.51.tar.bz2
$(touch_stamp)
define configure-rule
$(1)_install = $(DESTDIR)/$(1)-install-my-stamp
$(1)_builddir = $$($(1)_dir)/build
$(DESTDIR)/$(1)-install-my-stamp: $$($(1)_deps)
mkdir -p $$($(1)_builddir)
cd $$($(1)_builddir) && \
$$($(1)_env) ../configure --cache-file=$(SRCDIR)/$(1)-config.cache \
$$($(1)_configure)
$(NICE) make -C $$($(1)_builddir) $$($(1)_make_target) $(PARALLEL)
ifneq ($$($(1)_post_make),)
$$($(1)_post_make)
endif
touch $$#
.PHONY: build-$(1) clean-$(1)
build-$(1): $$($(1)_install)
clean-$(1):
-rm -fr $$($(1)_builddir)
endef
gmp_dir = src/gmp-4.3.2
gmp_env = CONFIG_SITE=$(SRCDIR)/config.site
gmp_configure = --prefix=$(DESTDIR) \
--disable-shared --enable-static --enable-cxx
gmp_deps = $(untar_dep)
gmp_make_target = install
$(eval $(call configure-rule,gmp))
mpfr_dir = src/mpfr-2.4.2
mpfr_env = CONFIG_SITE=$(SRCDIR)/config.site
mpfr_configure = --prefix=$(DESTDIR) \
--disable-shared --enable-static \
--with-gmp=$(DESTDIR)
mpfr_deps = $(untar_dep) $(gmp_install)
mpfr_make_target = install
$(eval $(call configure-rule,mpfr))
mpc_dir = src/mpc-0.8.1
mpc_env = CONFIG_SITE=$(SRCDIR)/config.site
mpc_configure = --prefix=$(DESTDIR) \
--disable-shared --enable-static \
--with-gmp=$(DESTDIR) --with-mpfr=$(DESTDIR)
mpc_deps = $(untar_dep) $(gmp_install) $(mpfr_install)
mpc_make_target = install
$(eval $(call configure-rule,mpc))
gcc_dir = src/gcc-4.7.2
gcc_env = CONFIG_SITE=$(SRCDIR)/config.site \
CFLAGS="-I/usr/include/i386-linux-gnu" \
CXXFLAGS="-I/usr/include/i386-linux-gnu"
gcc_configure = --prefix=$(DESTDIR) \
--libdir=$(DESTDIR)/lib \
--with-local-prefix=$(DESTDIR) \
--with-gmp=$(DESTDIR) --with-mpfr=$(DESTDIR) \
--with-mpc=$(DESTDIR) \
--disable-bootstrap \
--enable-languages=c,c++ \
--disable-libgomp --disable-multilib \
--disable-libmudflap --disable-libssp \
--disable-libquadmath \
--enable-rpath \
MAKEINFO=missing
gcc_deps = $(untar_dep) $(gmp_install) $(mpfr_install) $(mpc_install)
gcc_make_target =
gcc_post_make = make -C $(gcc_builddir) install
$(eval $(call configure-rule,gcc))
binutils_dir = src/binutils-2.24.51
#binutils_env = LDFLAGS=-Wl,-rpath\ $(DESTDIR)/lib
binutils_env = CONFIG_SITE=$(SRCDIR)/config.site \
CFLAGS="-I/usr/include/i386-linux-gnu" \
BOOT_LDFLAGS="-rpath-link=$(DESTDIR)/lib -rpath=$(DESTDIR)/lib"
binutils_configure = --prefix=$(DESTDIR) \
--libdir=$(DESTDIR)/lib \
--with-gmp=$(DESTDIR) \
--enable-rpath
binutils_deps = $(untar_dep) $(gmp_install)
#binutils_make_target = install
binutils_post_make = make -C $(binutils_builddir) install
$(eval $(call configure-rule,binutils))
.PHONY: env
env:
#echo export PATH=$(DESTDIR)/bin:\$$PATH
#echo export LIBRARY_PATH=/usr/lib/i386-linux-gnu
I was installing httpd-2.4.51 and needed to specify -rpath to compile the program. I use the linker flag -Wl,-rpath -Wl,LIBDIR.
Use commands:
sudo mv httpd.c /usr/lib #create a .c file and move it to the default directory for the library file
sudo gcc -o httpd httpd.c -L$--prefix=/usr/lib -lhttpd -Wl,-rpath=$--prefix=/usr/lib
Your can check where you have gcc installed:
whereis gcc
gcc: /usr/bin/gcc /usr/lib/gcc /usr/share/man/man1/gcc.1.gz
How do I add permissions to this simple make file?
all: shell ls cat groups
shell: shell.o cd.o
gcc shell.o cd.o -o shell
cat: cat.o
gcc -c cat.c -o cat
ls: ls.o header.h
gcc -c ls.c -o ls
groups: groups.o groups.h
gcc -c groups.c -o groups
shell.o: shell.c tlpi_hdr.h
gcc -c shell.c
cd.o: cd.c tlpi_hdr.h
gcc -c cd.c
cat.o: cat.c tlpi_hdr.h
gcc -c cat.c
ls.o: ls.c header.h
gcc -c ls.c
groups.o: groups.c groups.h
gcc -c groups.c
clean:
rm *.o shell cat ls groups
I need to run cat/ls/groups/cd within the shell that I created, but can't because it doesn't have permissions. How can I do this?
As an example, this rule:
groups: groups.o groups.h
gcc -c groups.c -o groups
tells GCC to produce an object file called groups (instead of the normal groups.o) because you included the -c option. Object files are not executables, so the compiler doesn't make them executable, hence your problem with the permissions. Note that the rule requires make to build groups.o, but then proceeds to ignore the object file because it recompiles the source code.
You wanted to write something more like:
groups: groups.o
gcc groups.o -o groups
groups.o: groups.h
You need to use a lot more macros — or you could leave the rules out of the makefile since make knows how to build groups from groups.c.
You should also be compiling with warning options. At minimum -Wall; preferably -Wall -Wextra -Werror (and I use still more options than these). You might want optimization (-O3); you might want debugging (-g). These are normally handled via setting macros and then using them in the commands.
I am confused by this command. The man page http://linux.die.net/man/1/ld says it "emulates the emulation linker. You can list the available emulations with the --verbose or -V options." But what does the "available emulations" mean?
For example, I use the following command to link objects:
ld -r -nostdlib -L/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib \
-m elf_x86_64 --verbose ./arch/x86/x86_64.o ./mini-os_app.o ./blkfront.o ./events.o ./fbfront.o \
./gntmap.o ./gnttab.o ./hypervisor.o ./kernel.o ./lock.o ./main.o ./mm.o ./netfront.o ./sched.o \
./lib/ctype.o ./lib/math.o ./lib/printf.o ./lib/stack_chk_fail.o ./lib/string.o ./lib/sys.o \
./lib/xmalloc.o ./lib/xs.o ./xenbus/xenbus.o ./console/console.o ./console/xencons_ring.o \
./console/xenbus.o ./lwip.a -L./arch/x86 -lx86_64 -lc -lglib-2.0 -lvmi -o ./mini-os.o
GNU ld (GNU Binutils for Ubuntu) 2.22
Supported emulations:
elf_x86_64
elf32_x86_64
elf_i386
i386linux
elf_l1om
elf_k1om
using internal linker script:
==================================================
(>>> scripts displayed here, neglected <<<)
==================================================
...
attempt to open /media/wind/lab/xen/xen/xen-4.4.0/stubdom/mini-os-x86_64-vmi/arch/x86/libx86_64.a succeeded
(>>> lots of *.o listed here for libc.a <<<)
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/mini-os-x86_64-vmi/arch/x86/libx86_64.a)mm.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/mini-os-x86_64-vmi/arch/x86/libx86_64.a)sched.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/mini-os-x86_64-vmi/arch/x86/libx86_64.a)setup.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/mini-os-x86_64-vmi/arch/x86/libx86_64.a)time.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/mini-os-x86_64-vmi/arch/x86/libx86_64.a)traps.o
...
attempt to open /media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libglib-2.0.a succeeded
(>>> why no *.o files listed here? <<<)
attempt to open /media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a succeeded
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-accessors.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-convenience.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-core.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-events.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-memory.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-read.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-interface.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-kvm.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-memory_cache.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-xen.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)lt1-libvmi_la-core.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)lt2-libvmi_la-memory.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-symbols.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)lt3-libvmi_la-core.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-kpcr.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)lt4-libvmi_la-memory.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-peparse.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-process.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)grammar.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)lexicon.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-cache.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-strmatch.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-file.o
As showed in the above outputs, it seems that each *.a library should have their own *.o listed. But what is the meaning if no *.o listed for a certain *.a library,such as glib-2.0.a showed above ?
Thank you in advance!
The ld -m option is used while linking .o files to create an executable file for a hardware platform provided as an argument with -m option.
E.g. if you specify ld -m elf_x86_64 ..., an executable file is created (assuming no error occurred) that can run on a x86_64 system. This is generally used during cross compiling. i.e. in the situation when you are trying to create an executable for a platform different from the one it is being built.
I'm tryin to follow the direction to install id3v2. I installed id3lib and did not receive any errors. I now try to do "make" and then "make install" as they suggest that I do.
I get the following responses when I go through the process.
I was under the assumption that I would be able to use the program by typing "id3v2 ....."
However, it seems that the system doesn't find the command. Does that mean the program was not installed? If so, how would I try to find a solution?
[root#ip-xxx-xxx-xxx-xxx id3v2-0.1.12]# make
g++ -Wall -I/opt/local/include/ -DVERSION="\"0.1.12\"" -c -o convert.o convert.cpp
g++ -Wall -I/opt/local/include/ -DVERSION="\"0.1.12\"" -c -o list.o list.cpp
g++ -Wall -I/opt/local/include/ -DVERSION="\"0.1.12\"" -c -o id3v2.o id3v2.cpp
g++ -Wall -I/opt/local/include/ -DVERSION="\"0.1.12\"" -c -o genre.o genre.cpp
g++ -L/opt/local/lib/ -pedantic -Wall -g -o id3v2 convert.o list.o id3v2.o genre.o -lz -lid3
[root#ip-xxx-xxx-xxx-xxx id3v2-0.1.12]# make install
install -c -s id3v2 /opt/local/bin/id3v2
nroff -man id3v2.1 > /opt/local/share/man/man1/id3v2.1
[root#ip-xxx-xxx-xxx-xxx id3v2-0.1.12]# id3v2
-bash: id3v2: command not found
I've looked at the make file itself and it says:
install: all
install -c -s id3v2 ${PREFIX}/bin/id3v2
nroff -man id3v2.1 > ${PREFIX}/share/man/man1/id3v2.1
The Prefix hard coded into the make file is:
/opt/local
Now I think it must be true that it is installing it in the wrong directory. Is it normal to adjust the Makefile? am I barking up the wrong tree?
Most likely path where you installed is not in $PATH. You can either call it with the full path:
/opt/local/bin/id3v2
or add this path to your $PATH:
export $PATH=$PATH:/opt/local/bin
To make it permanent append this line to $HOME/.profile