When generating the configuration file, is there a reason to use
"doxygen -s -g ini"
instead of just
"doxygen -g ini"?
From the online doxygen manual:
If -s is specified the comments in the config file will be omitted. If configName is omitted 'Doxyfile' will be used as a default.
Related
I've got a makefile recipe that builds a shared library (an alsa plugin). If I build the library outside if yocto everything works correctly and alsa will link to the library.
However if I build it with yocto, even though the log is error free, when I try and run alsa, I get an error "Cannot open shared library". The library is installed in location referenced by the error message and it's permissions are correct.
From within the recipe if I print out what BUILD_LDFLAGS is set to I notice the it's pointing to the x86_64-linux (build system) libraries instead of the 'MACHINE' libraries (example: -L//.build-yocto/tmp/sysroots/x86_64-linux/lib"
My questions are:
Is the BUILD_LDFLAGS the source of my problem?
If so how do I remedy it?
If not BUILD_LDFLAGS, any idea what is the problem.
Here is a copy of my recipe bb file:
SUMMARY = "..."
LICENSE = "CLOSED"
#Package release number
PR = "r0"
###################################################################
#The following lines tell yocto where to get the source code from
# This section is for git. Comment out ALL this section if
# you DO NOT want to pull from a git repo (local or remote).
# If pulling from git uncomment and modify paths.
###################################################################
#Uncomment following line to pull from REMOTE git repo
#SRC_URI = "git://gitpath;protocol=ssh;branch=master"
#Uncomment following line and modify path to pull from LOCAL git repo clone
##SRC_URI = "git:///localgitpath;protocol=file;branch=master"
#Change hash to match the commit you want yocto to use
##SRCREV="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
##S = "${WORKDIR}/git/"
# End of git section
###################################################################
#The following lines tell yocto where to use a local file system
# for the source. Uncomment all lines and modify paths
###################################################################
SRC_URI = ""
inherit externalsrc
EXTERNALSRC = "/home/<my_path>"
EXTERNALSRC_BUILD = "/home/<my_path>"
# End of local file system section
##################################################################
#END of where to get source code
##################################################################
#Ignore vendor ldflags checking and use ours
INSANE_SKIP_${PN} = "ldflags"
#Don't strip debug symbols
INHIBIT_PACKAGE_STRIP = "1"
INHIBIT_SYSROOT_STRIP = "1"
SOLIBS = ".so"
#Tell yocto that the .so files are real and not sym-links.
FILES_SOLIBSDEV = ""
#/usr/lib/alsa-lib
FILES_${PN} += "${libdir}/alsa-lib"
#/usr/<PATH>
FILES_${PN} += "${prefix}/<PATH>"
DEPENDS += "alsa-lib"
EXTRA_OEMAKE += "'CC=${CC}' 'RANLIB=${RANLIB}' 'AR=${AR}' 'CFLAGS=${CFLAGS} -I${S}/include' 'BUILDDIR=${S}' 'DESTDIR=${D}'"
TARGET_CFLAGS += "-DPIC -fPIC -Wall -Wextra -O2 -g -I./include -I<path> -I-I<path2> -I<path3> -lasound"
TARGET_LDFLAGS += "-shared -lasound"
do_configure() {
oe_runmake -f Makefile.yocto clean
}
do_compile() {
# unset LDFLAGS TARGET_LDFLAGS BUILD_LDFLAGS
echo " Werkdir ${WORKDIR}"
echo " Compiler ${CC}"
echo " BUILD_LDFLAGS ${BUILD_LDFLAGS}"
echo " LDFLAGS ${LDFLAGS}"
echo " TARGET_LDFLAGS ${TARGET_LDFLAGS}"
oe_runmake -f Makefile.yocto all 'CC=${CC}'
}
do_install() {
install -d ${D}${libdir}
install -d ${D}${libdir}/alsa-lib
install -d ${D}${bindir}
install -d ${D}${prefix}
install -d ${D}${prefix}/<PATH>
install -m 0644 <path_n>lib1.so ${D}${libdir}
install -m 0644 <path_n>lib2.so.so ${D}${libdir}
install -m 0644 <path_n>lib3.so.so ${D}${libdir}
install -m 0644 <path_n>lib4.so.so ${D}${libdir}
install -m 0644 <path_n>lib1pcm_plugin.so ${D}${libdir}/alsa-lib
install -m 0755 <path_n>app1 ${D}${bindir}
install -m 0755 <path_n>app2 ${D}${bindir}
install -m 0755 <path_n>app3 ${D}${bindir}
install -m 0755 <path_n>app4 ${D}${bindir}
install -m 0755 <path_n>app5 ${D}${bindir}
install -m 0755 <path_n>app6 ${D}${bindir}
install -m 0755 <path_n>app7 ${D}${bindir}
install -m 0755 <path_n>app8 ${D}${bindir}
}
Makefile:
# Makefile template for shared library
#Yocto will pass in the CC flag so this is commented out. Otherwise the correct compiler won't be used
#CC = gcc # C compiler
#These are here to allow a build outside of Yocto (testing the build). Yocto's CFLAGS
#and LDFLAGS will override these.
CFLAGS += -fPIC -Wall -Wextra -O2 -g -I<path1> -I<path2> -I<path2> # C flags
LDFLAGS = -shared # linking flags
RM = rm -f # rm command
TARGET_LIB = libasoundplugin.so # target lib
LIB1=lib1
PATH1=<path1>
LIB2=lib2
PATH2=<path2>
INCLUDE_FLAGS = -L$(PATH1) -l$(LIB1I) \
-L$(PATH2) -l$(LIB2) \
-lasound
SRCS = source.c
OBJS = $(SRCS:.c=.o)
.PHONY: all
all: ${TARGET_LIB}
$(TARGET_LIB): $(OBJS)
$(CC) ${LDFLAGS} ${INCLUDE_FLAGS} -o $# $^
$(SRCS:.c=.d):%.d:%.c
$(CC) $(CFLAGS) -MM $< >$#
include $(SRCS:.c=.d)
.PHONY: clean
clean:
-${RM} ${TARGET_LIB} ${OBJS} $(SRCS:.c=.d)
Thanks!
Is the BUILD_LDFLAGS the source of my problem?
No. BUILD_LDFLAGS is used to build native packages, while you build a target package. In your case TARGET_LDFLAGS variable will be used as LDFLAGS source.
Here is a copy of my recipe bb file
Where does it come from? Did you write it from a template?
As I can see there is a recipe for alsa plugins, maybe you can add your plugin to this recipe?
You can also take as example the recipe for a2jmidid, it is close to what you are trying to do as I understand. It does nothing special, except for setting dependencies, getting sources, adding certain ld flags and passing resulting files to the package.
Regarding the Makefile (I suppose it is also your recipe):
First of all there is no need to have a separate Makefile for yocto.
#Yocto will pass in the CC flag so this is commented out. Otherwise the correct compiler won't be used
#CC = gcc # C compiler
You are passing CC from your .bb recipe (even twice: via EXTRA_OEMAKE and in do_compile). There is no need to comment out CC variable, as definitions inside Makefile have lower priority compared to definitions passed as command line arguments.
Why do you need INCLUDE_FLAGS variable? I don't understand what does it do (except for passing to gcc some flags for the third time).
Ultimately, you can go to the workdir, open file temp/log.do_compile and you will see which commands were executed to compile your plugin. Compare it to the settings you use to compile it manually, and you will see what is the difference between successful and unsuccessful builds.
I have a project with a Makefile in it, on Unix console it works fine, compiles, builds and I can run the binary at the end.
I imported the project into Eclipse workspace and somehow Makefile module of Eclipse cannot build the project now. It gives the following error:
g++: error: /src/main: No such file or directory
Whereas there should have been
g++ -I $(APR_INCLUDE) -I $(CMS_HOME)/src/main
which uses two make variables. I already put them before this line and define them as :
export APR_INCLUDE=/usr/include/apr-1
export CMS_HOME=~/Desktop/activemq-cpp-library-3.8.4
Same Makefile is fine with console, but not with Eclipse, which is weird.
Any thoughts?
Here is where I put my export lines:
obstacleDetection_cpp: src/obstacleDetection.cpp protoc_middleman
export APR_INCLUDE=/usr/include/apr-1
export CMS_HOME=~/Desktop/activemq-cpp-library-3.8.4
g++ -I $(APR_INCLUDE) -I $(CMS_HOME)/src/main -g -o src/obstacleDetection.o -c src/obstacleDetection.cpp
cd libs && cp $(CMS_HOME)/src/main/.libs/libactivemq-cpp.so.18.0.4 . && ln -sf libactivemq-cpp.so.18.0.4 libactivemq-cpp.so.18
g++ -L $(CMS_HOME)/src/main/.libs/ -g -o bin/obstacleDetection src/obstacleDetection.o src-gen/Point.pb.cc src-gen/Point.pb.h -lactivemq-cpp -lssl -lprotobuf -pthread
#echo "Success. Run the executable from the binary directory with: LD_LIBRARY_PATH=../libs/ ./obstacleDetection"
This is not right:
obstacleDetection_cpp: src/obstacleDetection.cpp protoc_middleman
export APR_INCLUDE=/usr/include/apr-1
export CMS_HOME=~/Desktop/activemq-cpp-library-3.8.4
g++ $(APR_INCLUDE) -I $(CMS_HOME)/src/main ...
All lines in the recipe (that is, lines that are indented with a TAB in a target context like this) are passed to the shell. These are not make variable assignments. There are two things wrong with that:
First, each logical line in the recipe is passed to a new shell. That means any changes to the process context (such as the environment or the working directory) are present only for the duration of that logical line; once the shell processing that line exits, all those changes are lost. So, these lines have no impact: they set an environment variable in the shell, then the shell exits and that setting is gone.
Second, the variable references you make in your compile line, such as $(APR_INCLUDE), are make variable references, not environment variable references. So even if those environment variable assignments still had effect, they would not be used because you're not referring to environment variables here.
You want to create make variable assignments. That can only be done outside of a recipe. Also, you don't need to export them because only make needs to see them (make will expand them before invoking the shell). So, your makefile should look like this:
APR_INCLUDE = /usr/include/apr-1
CMS_HOME = $(HOME)/Desktop/activemq-cpp-library-3.8.4
obstacleDetection_cpp: src/obstacleDetection.cpp protoc_middleman
g++ -I $(APR_INCLUDE) -I $(CMS_HOME)/src/main -g -o src/obstacleDetection.o -c src/obstacleDetection.cpp
cd libs && cp $(CMS_HOME)/src/main/.libs/libactivemq-cpp.so.18.0.4 . && ln -sf libactivemq-cpp.so.18.0.4 libactivemq-cpp.so.18
g++ -L $(CMS_HOME)/src/main/.libs/ -g -o bin/obstacleDetection src/obstacleDetection.o src-gen/Point.pb.cc src-gen/Point.pb.h -lactivemq-cpp -lssl -lprotobuf -pthread
#echo "Success. Run the executable from the binary directory with: LD_LIBRARY_PATH=../libs/ ./obstacleDetection"
I've followed the guidance I found here.
I have almost completed the work. The following section is the paragraph of batch conversion work. I have created a batch file to convert a lot of DLLs pre-built by MSVC in Matlab 2011b Windows 7(64-bit).
set path=C:\MinGW64\bin;C:\mingw\msys\bin;
mkdir lib
mkdir bin
#echo y |copy *.dll .\bin
#echo y |copy *.lib .\lib
#echo EXPORTS >libmex.def
#echo EXPORTS >libmx.def
#echo EXPORTS >libmat.def
#echo EXPORTS >libeng.def
#echo EXPORTS >libmwlapack.def
c:\mingw64\bin\pexports ./bin/libmex.dll | sed "s/^_//" > libmex.def
c:\mingw64\bin\pexports ./bin/libmat.dll | sed "s/^_//" > libmat.def
c:\mingw64\bin\pexports ./bin/libeng.dll | sed "s/^_//" > libeng.def
c:\mingw64\bin\pexports ./bin/libmwlapack.dll | sed "s/^_//" >libmwlapack.def
gendef ./bin/libmx.dll
echo "Add the mexErrMsgTxt string to each def file,"
echo "then press any key to continue the conversion process"
pause
lib /machine:x64 /def:libmex.def /name:.\bin\libmex.dll /out:.\lib\libmex.lib
lib /machine:x64 /def:libmx.def /name:.\bin\libmx.dll /out:.\lib\libmx.lib
lib /machine:x64 /def:libmat.def /name:.\bin\libmat.dll /out:.\lib\libmat.lib
lib /machine:x64 /def:libeng.def /name:.\bin\libeng.dll /out:.\lib\libeng.lib
lib /machine:x64 /def:libmwlapack.def /name:.\bin\libmwlapack.dll /out:.\lib\libmwlapack.lib
c:\mingw64\bin\x86_64-w64-mingw32-dlltool --kill-at -U -d libmex.def -l /lib/libmex.a
c:\mingw64\bin\x86_64-w64-mingw32-dlltool --kill-at -U -d libmat.def -l ./lib/libmat.a
c:\mingw64\bin\x86_64-w64-mingw32-dlltool --kill-at -U -d libeng.def -l ./lib/libeng.a
c:\mingw64\bin\x86_64-w64-mingw32-dlltool --kill-at -U -d libmx.def -l./lib/libmx.a
c:\mingw64\bin\x86_64-w64-mingw32-dlltool --kill-at -U -d libmwlapack.def -l ./lib/libmwlapack.a
Makefile for engwindemo.exe:
LIBS= -Lc:/mingw64/lib ../lib/libeng.a ../lib/libmx.a ../lib/
libmex.a ../lib/libmat.a
CC=c:/mingw64/bin/gcc -m64 -O3 -I../include -Ic:/mingw64/include
EXE=../bin/engwindemo.exe
SRC=engwindemo.c
all:$(EXE)
$(EXE): $(SRC)
$(CC) $(SRC) $(LIBS) -L../lib -ladvapi32 -luser32 -lgdi32 -lkernel32 -
lmingwex -o $(EXE)
#rm -f *.o*
Using (mingw64) gcc, the compiling and linking processes is ok. Execute engwindemo.exe, I get this error:
_engClose entry point error (in libeng.dll)
In mingw64, how can I build a stand-alone application (engwindemo.exe) which calls from the functions built-in the libeng.dll (Matlab R2011b)?
Thank everyone response! I have built up successfully! In the Matlab R2011b
win32/64, just setting up in the cygwin(x86_64-w64-mingw32-gcc 4.5.2) environment without any dll file conversion.
The part of primary setting is as following
Set the MATLABROOT in short filename form (long filename may be ok.)
MATLABROOT=c:/Progra~1/MATLAB/R2011b
linking the primary libraries built by MSVC
LIBS= -L$(MATLABROOT)/bin/win64 -lmex -lmx -lmwlapack -lmwblas -leng
declare the gcc with the flags
CC=x86_64-w64-mingw32-gcc
CFLAG=-Wall -m64 -O3 -I$(MATLABROOT)/extern/include
MEXFLAG=-m64 -shared -DMATLAB_MEX_FILE -I$(MATLABROOT)/extern/include -Wl,--export-all-symbols $(LIBS)
Others additional parameters to keep compiler happy.
And finally, in the cygwin consloe or mingw64 shell just make this project.
When using inline C with Varnish I've not been able to get /etc/varnish/default
to be happy at startup.
I've tested inline C with varnish for two things: GeoIP detection and Anti-Site-Scraping functions.
The DAEMON_OPTS always complains even though I'm following what other seem
to indicate works fine.
My problem is that this command line start up works:
varnishd -f /etc/varnish/varnish-default.conf -s file,/var/lib/varnish/varnish_storage.bin,512M -T 127.0.0.1:2000 -a 0.0.0.0:8080 -p 'cc_command=exec cc -fpic -shared -Wl,-x -L/usr/include/libmemcached/memcached.h -lmemcached -o %o %s'
But it errors out with trying to start up from default start scripts:
/etc/default/varnish has this in it:
DAEMON_OPTS="-a :8080 \
-T localhost:2000 \
-f /etc/varnish/varnish-default.conf \
-s file,/var/lib/varnish/varnish_storage.bin,512M \
-p 'cc_command=exec cc -fpic -shared -Wl,-x -L/usr/include/libmemcached/memcached.h -lmemcached -o %o %s'"
The error is:
# /etc/init.d/varnish start
Starting HTTP accelerator: varnishd failed!
storage_file: filename: /var/lib/varnish/vbox.local/varnish_storage.bin size 512 MB.
Error:
Unknown parameter "'cc_command".
If I try change the last line to:
-p cc_command='exec cc -fpic -shared -Wl,-x -L/usr/include/libmemcached/memcached.h -lmemcached -o %o %s'"
It's error is now:
# /etc/init.d/varnish start
Starting HTTP accelerator: varnishd failed!
storage_file: filename: /var/lib/varnish/vbox.local/varnish_storage.bin size 512 MB.
Error: Unknown storage method "hared"
It's trying to interpret the '-shared' as -s hared and 'hared' is not a storage type.
For both GeoIP and the Anti-Site-Scrape I've used the exact recommended daemon options
plus have tried all sorts of variations like adding ' and '' but no joy.
Here is a link to the instruction I've followed that work fine except the DAEMON_OPTS part.
http://drcarter.info/2010/04/how-fighting-against-scraping-using-varnish-vcl-inline-c-memcached/
I'm using Debian and the exact DAEMON_OPTS as stated in the instructions.
Can anyone help with a pointer on what's going wrong here?
Even if Jacob will probably never read this, visitors from the future might appreciate what I'm going to write.
I believe I know what's wrong, and it looks like a Debian-specific problem, at least verified on Ubuntu 11.04 and Debian Squeeze.
I traced the execution from my /etc/default/varnish that contains the $DAEMON_OPTS to the init script.
In the init script /etc/init.d/varnish, the start_varnishd() function is:
start_varnishd() {
log_daemon_msg "Starting $DESC" "$NAME"
output=$(/bin/tempfile -s.varnish)
if start-stop-daemon \
--start --quiet --pidfile ${PIDFILE} --exec ${DAEMON} -- \
-P ${PIDFILE} ${DAEMON_OPTS} > ${output} 2>&1; then
log_end_msg 0
else
log_end_msg 1
cat $output
exit 1
fi
rm $output
}
So I modified it to print the full start-stop-daemon command line, like:
start_varnishd() {
log_daemon_msg "Starting $DESC" "$NAME"
output=$(/bin/tempfile -s.varnish)
+ echo "start-stop-daemon --start --quiet --pidfile ${PIDFILE} --exec ${DAEMON} -- -P ${PIDFILE} ${DAEMON_OPTS} > ${output} 2>&1"
if start-stop-daemon \
--start --quiet --pidfile ${PIDFILE} --exec ${DAEMON} -- \
-P ${PIDFILE} ${DAEMON_OPTS} > ${output} 2>&1; then
log_end_msg 0
So I got a command line echoed on STDOUT, and copied-pasted it into my shell. And, surprise! It worked. WTF?
Repeated again to be sure. Yes, it works. Mmh. Could it be another of those bash/dash corner cases?
Let's try feeding the start-stop-daemon command line to bash, and see how it reacts:
start_varnishd() {
log_daemon_msg "Starting $DESC" "$NAME"
output=$(/bin/tempfile -s.varnish)
if bash -c "start-stop-daemon \
--start --quiet --pidfile ${PIDFILE} --exec ${DAEMON} -- \
-P ${PIDFILE} ${DAEMON_OPTS} > ${output} 2>&1"; then
log_end_msg 0
else
log_end_msg 1
cat $output
exit 1
fi
rm $output
}
Yes, it works just fine, at least for my case.
Here's the relevant part of my /etc/default/varnish:
...
## Alternative 2, Configuration with VCL
#
# Listen on port 6081, administration on localhost:6082, and forward to
# one content server selected by the vcl file, based on the request. Use a 1GB
# fixed-size cache file.
#
DAEMON_OPTS="-a :6081 \
-T localhost:6082 \
-f /etc/varnish/geoip-example.vcl \
-S /etc/varnish/secret \
-s malloc,100M \
-p 'cc_command=exec cc -fpic -shared -Wl,-x -L/usr/include/GeoIP.h -lGeoIP -o %o %s'"
...
I've seen posts where someone tried to work around this problem by moving the compile command into a separated shell script. Unfortunately that doesn't change the fact that start-stop-daemon is going to pass the $DAEMON_OPTS var through dash, and that will result in mangled options.
Would be something along the lines of:
-p 'cc_command=exec /etc/varnish/compile.sh %o %s'"
And then the compile.sh script as:
#!/bin/sh
cc -fpic -shared -Wl,-x -L/usr/include/GeoIP.h -lGeoIP -o $#
but it doesn't work, so just patch your init scripts, and you're good to go!
Hope you can find this information useful.
You can try using :-
DAEMON_OPTS="-a :8080 \
-T localhost:2000 \
-f /etc/varnish/varnish-default.conf \
-s file,/var/lib/varnish/varnish_storage.bin,512M \
-p cc_command='exec cc -fpic -shared -Wl,-x -L/usr/include/libmemcached/memcached.h -lmemcached -o %o %s'"
Obviously, your startup script interpreting the DAEMON_OPTS is not prepared for whitespace (even within single quotes). At my Fedora (15) installation, the suggested solution works fine; the arguments get interpreted correctly because the "$*" bash parameter is passed in /etc/init.d/varnish and in /etc/init.d/functions in daemon().
Did you get your startup scripts from a package or did you make custom scripts?
This isn't directly related to the question, but you may find yourself here if you are working through the Varnish Tutorial - Put Varnish on port 80.
For recent installs of Varnish on Debian systems the configuration for varnishd startup options can be found in /etc/systemd/system/multi-user.target.wants/varnish.service. The documented way of changing the port via /etc/default/varnish still exists, but is no longer functional unless you change your system to use init scripts rather than systemd.
After you've changed your options in /etc/systemd/system/multi-user.target.wants/varnish.service, don't forget to run systemctl daemon-reload, which will catalog the changes for executing the program.
It is an odd behaviour seen only on Solaris that when I try to copy a symbolic link with the "cp -R -P" command to some other folder with a different name, it copies the entire directory/file it's pointing to.
For example:
link -> dir
cp -R -P link folder/new_link
I believe the "-d" argument is what you need.
As per the cp man page:
-d same as --no-dereference --preserve=link
Example:
cp -d -R -P link folder/new_link
I was using "cp -d" and that worked for me.
The cp man page seems to say that you want to use an '-H' to preserve symlinks within the source directory.
You might consider copying via tar, like tar -cf - srcdir|(cd somedir;tar -xf -)
Try using cpio (with the -p (pass) option) or the old tar in a pipe trick.