Matlab 2011b and mingw64 - matlab

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.

Related

Matlab Mex compilation error

I’m using the Random Forest library for Matlab (link). I’m using it for classification. On Windows it works very well out of the box (precombiled mex files) but I also want to run it on a CentOS cluster.
I have tried to compile it on the cluster by executing make mex but I’m getting an error. The output is as follows:
rm twonorm_test -rf
rm tempbuild/*.o *.o -rf
rm *~ -rf
rm *.mexw32 twonorm_test -rf
rm *.mexa64 -rf
rm classRF -rf
rm *.exe -rf
echo 'Compiling classTree.cpp'
Compiling classTree.cpp
g++ -fpic -O2 -funroll-loops -msse3 -c src/classTree.cpp -o tempbuild/classTree.o
echo 'Compiling Cokus (random number generator)'
Compiling Cokus (random number generator)
g++ -fpic -O2 -funroll-loops -msse3 -c src/cokus.cpp -o tempbuild/cokus.o
echo 'Compiling rfsub.f (fortran subroutines)'
Compiling rfsub.f (fortran subroutines)
gfortran -O2 -fpic -c src/rfsub.f -o rfsub.o
echo 'Compiling rfutils.cpp'
Compiling rfutils.cpp
g++ -fpic -O2 -funroll-loops -msse3 -c src/rfutils.cpp -o tempbuild/rfutils.o
echo 'Generating Mex'
Generating Mex
mex src/mex_ClassificationRF_train.cpp src/classRF.cpp tempbuild/classTree.o tempbuild/rfutils.o rfsub.o tempbuild/cokus.o -o mexClassRF_train -lgfortran -lm -DMATLAB -g
Unknown MEX argument '-o'.
make: *** [mex_classRF] Error 255
Does somebody knows how to solve this issue? If you want, you can take RF_MexStandalone-v0.02.zip from the above link and then go to randomforest-matlab/RF_Reg_C/Makefile.
Edit: I have change -o to -output but now the output is the following:
rm twonorm_test -rf
rm tempbuild/*.o *.o -rf
rm *~ -rf
rm *.mexw32 twonorm_test -rf
rm *.mexa64 -rf
rm classRF -rf
rm *.exe -rf
echo 'Compiling classTree.cpp'
Compiling classTree.cpp
g++ -fpic -O2 -funroll-loops -msse3 -c src/classTree.cpp -o tempbuild/classTree.o
echo 'Compiling Cokus (random number generator)'
Compiling Cokus (random number generator)
g++ -fpic -O2 -funroll-loops -msse3 -c src/cokus.cpp -o tempbuild/cokus.o
echo 'Compiling rfsub.f (fortran subroutines)'
Compiling rfsub.f (fortran subroutines)
gfortran -O2 -fpic -c src/rfsub.f -o rfsub.o
echo 'Compiling rfutils.cpp'
Compiling rfutils.cpp
g++ -fpic -O2 -funroll-loops -msse3 -c src/rfutils.cpp -o tempbuild/rfutils.o
echo 'Generating Mex'
Generating Mex
mex src/mex_ClassificationRF_train.cpp src/classRF.cpp tempbuild/classTree.o tempbuild/rfutils.o rfsub.o tempbuild/cokus.o -output mexClassRF_train -lgfortran -lm -DMATLAB -g
Building with 'g++'.
cc1plus: error: unrecognized command line option "-std=c++11"
make: *** [mex_classRF] Error 255
I did not find an option -std=c++11 in the makefile.
The error is quite self-explanatory: the option -o is not recognized. If you type mex -help you see the options mex accepts. Try to replace -o with -output.
EDIT regarding the std=c++11 option, you are probably using an old version of gcc compiler. You can either change it to std=c++0x which is the equivalent option (but note that some features of the c++11 standard may not be present\implemented), or upgrade to an up-to-date version of gcc.
If you need more help, please report the output of g++ --version.

Eclipse Makefile: Make Variables are skipped

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"

Build ICU for 64 bit iOS

I'm trying to move my app to 64 bit arm processors (and 64 bit simulator), and for that I need to recompile the ICU library (49).
After three days I reached the point where the library compiles fine, and the script I'm using puts together various architectures into one (snippet):
# ...
#x86_64
DEVROOT=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer
SDKROOT=$DEVROOT/SDKs/iPhoneSimulator7.0.sdk
SYSROOT=$SDKROOT
export CFLAGS="-I$SDKROOT/usr/include/ -I./include/ $ICU_FLAGS -arch x86_64 -pipe -no-cpp-precomp -isysroot $SDKROOT -miphoneos-version-min=7.0 -O3 -DU_HAVE_GCC_ATOMICS=0"
export CXXFLAGS="$CFLAGS"
export CC="$TOOLCHAINSROOT/usr/bin/clang"
export CXX="$TOOLCHAINSROOT/usr/bin/clang++"
export LDFLAGS="-L$SDKROOT/usr/lib/ -isysroot $SDKROOT -Wl,-dead_strip -miphoneos-version-min=7.0"
mkdir -p $BUILDDIR/iosbuild/x86_64
cd $BUILDDIR/iosbuild/x86_64
gnumake clean
sh $ICU_PATH/source/configure --host=arm-apple-darwin --enable-static --disable-shared -with-cross-build=$BUILDDIR/hostbuild --prefix=$BUILDDIR/iosbuild/x86_64 --with-data-packaging=library
gnumake
gnumake clean install
# ...
#x86_64
mkdir -p ${BUILDDIR}/iosbuild/x86_64/lib/libicudata
cd ${BUILDDIR}/iosbuild/x86_64/lib/libicudata
ar -x "${BUILDDIR}/iosbuild/x86_64/lib/libicudata.a"
mkdir -p ${BUILDDIR}/iosbuild/x86_64/lib/libicui18n
cd ${BUILDDIR}/iosbuild/x86_64/lib/libicui18n
ar -x "${BUILDDIR}/iosbuild/x86_64/lib/libicui18n.a"
mkdir -p ${BUILDDIR}/iosbuild/x86_64/lib/libicuio
cd ${BUILDDIR}/iosbuild/x86_64/lib/libicuio
ar -x "${BUILDDIR}/iosbuild/x86_64/lib/libicuio.a"
mkdir -p ${BUILDDIR}/iosbuild/x86_64/lib/libicule
cd ${BUILDDIR}/iosbuild/x86_64/lib/libicule
ar -x "${BUILDDIR}/iosbuild/x86_64/lib/libicule.a"
mkdir -p ${BUILDDIR}/iosbuild/x86_64/lib/libiculx
cd ${BUILDDIR}/iosbuild/x86_64/lib/libiculx
ar -x "${BUILDDIR}/iosbuild/x86_64/lib/libiculx.a"
mkdir -p ${BUILDDIR}/iosbuild/x86_64/lib/libicutest
cd ${BUILDDIR}/iosbuild/x86_64/lib/libicutest
ar -x "${BUILDDIR}/iosbuild/x86_64/lib/libicutest.a"
mkdir -p ${BUILDDIR}/iosbuild/x86_64/lib/libicutu
cd ${BUILDDIR}/iosbuild/x86_64/lib/libicutu
ar -x "${BUILDDIR}/iosbuild/x86_64/lib/libicutu.a"
mkdir -p ${BUILDDIR}/iosbuild/x86_64/lib/libicuuc
cd ${BUILDDIR}/iosbuild/x86_64/lib/libicuuc
ar -x "${BUILDDIR}/iosbuild/x86_64/lib/libicuuc.a"
ar -qc ${BUILDDIR}/iosbuild/x86_64/lib/libcombinedicu.a ${BUILDDIR}/iosbuild/x86_64/lib/libicudata/*.o ${BUILDDIR}/iosbuild/x86_64/lib/libicudata/*.ao ${BUILDDIR}/iosbuild/x86_64/lib/libicuuc/*.ao ${BUILDDIR}/iosbuild/x86_64/lib/libicui18n/*.ao ${BUILDDIR}/iosbuild/x86_64/lib/libicuio/*.ao ${BUILDDIR}/iosbuild/x86_64/lib/libicule/*.ao ${BUILDDIR}/iosbuild/x86_64/lib/libiculx/*.ao ${BUILDDIR}/iosbuild/x86_64/lib/libicutest/*.ao ${BUILDDIR}/iosbuild/x86_64/lib/libicutu/*.ao ${BUILDDIR}/iosbuild/x86_64/lib/libicuuc/*.ao
# ...
#put them together
lipo -create -arch x86_64 "${BUILDDIR}/iosbuild/x86_64/lib/libcombinedicu.a"
-arch i386 "${BUILDDIR}/iosbuild/i386/lib/libcombinedicu.a"
"${BUILDDIR}/iosbuild/arm64/lib/libcombinedicu.a"
"${BUILDDIR}/iosbuild/armv7s/lib/libcombinedicu.a"
-arch armv7 "${BUILDDIR}/iosbuild/armv7/lib/libcombinedicu.a"
-o "$FRAMEWORK_DIR/Versions/Current/$FRAMEWORK_NAME"
The problem is, when I'm compiling the app from XCode (for the 64 bit simulator), I get the following errors regarding the built ICU framework:
ld: warning: directory not found for option '-F"/Users/gliptak/ac/m-220/Sources/VBExplorer/BIMxPro/../BIMxEngine/extern/icu"'
duplicate symbol _OSAtomicIncrement32 in:
/Users/gliptak/ac/m-220/Sources/VBExplorer/BIMxEngine/extern/icu/ICU.framework/ICU(unistr.ao)
/Users/gliptak/ac/m-220/Sources/VBExplorer/BIMxEngine/extern/icu/ICU.framework/ICU(mutex.ao)
duplicate symbol _OSAtomicIncrement32Barrier in:
/Users/gliptak/ac/m-220/Sources/VBExplorer/BIMxEngine/extern/icu/ICU.framework/ICU(unistr.ao)
/Users/gliptak/ac/m-220/Sources/VBExplorer/BIMxEngine/extern/icu/ICU.framework/ICU(mutex.ao)
duplicate symbol _OSAtomicDecrement32 in:
/Users/gliptak/ac/m-220/Sources/VBExplorer/BIMxEngine/extern/icu/ICU.framework/ICU(unistr.ao)
/Users/gliptak/ac/m-220/Sources/VBExplorer/BIMxEngine/extern/icu/ICU.framework/ICU(mutex.ao)
duplicate symbol _OSAtomicDecrement32Barrier in:
/Users/gliptak/ac/m-220/Sources/VBExplorer/BIMxEngine/extern/icu/ICU.framework/ICU(unistr.ao)
/Users/gliptak/ac/m-220/Sources/VBExplorer/BIMxEngine/extern/icu/ICU.framework/ICU(mutex.ao)
...
ld: 64 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
As far as I can tell the mentioned functions are declared in system headers, and are not inline, so how can this error exist?
Do you have any ideas what I might do wrong?
UPDATE: indeed, those functions are static inline, so they cause the problem. So the question is now how do I avoid duplication?
UPDATE: tried the -std=gnu89 flag for the C compiler, no effect...
Found a solution here (confirmed working building on/for Mavericks). Could also be resolved using SVN trunk of icu4c, since that uses C++11 barriers instead.

How can I get pkg-config to work within eclipse juno (Mac OS X)?

I try to get gtkmm running within eclipse. This is my makefile (without the cleaning):
all : main.cpp
#export PATH+=/opt/local/bin;
#echo PATH=$(PATH);
g++ -v `pkg-config gtkmm-2.4 --cflags` \
-O0 -g3 -Wall -S \
-o main.o main.cpp;
g++ -v -o main.exe main.o \
`pkg-config gtkmm-2.4 \
--libs` ;
In the Console I get (amongst other output):
PATH=/usr/bin:/bin:/usr/sbin:/sbin
g++ -v `pkg-config gtkmm-2.4 --cflags` \
-O0 -g3 -Wall -S \
-o main.o main.cpp;
/bin/sh: pkg-config: command not found
I did:
ln -s /usr/bin/pkg-config /opt/local/bin/pkg-config
And when I type
/usr/bin/pkg-config
in Terminal, I get:
Must specify package names on the command line
So I assume pkg-config works in the "Terminal" ... But not in eclipse.
What can I do?
Thanks!
Nils
I don't know exactly what solved my Problem, since now, it works.
I guess it was one of the following:
makefile now looks like this:
all: main.cpp
g++ -v `pkg-config gtkmm-2.4 --cflags`-O0 -g3 -Wall -c -o main.o main.cpp;
g++ -v -o main.exe main.o `pkg-config gtkmm-2.4 --libs`
clean:
rm -f main.exe main.o
I have smybolic link towards pkg-config within /bin:
sudo ln -s /opt/local/bin/pkg-config /bin/pkg-config
I installed XQuartz
I updated MacPorts and all outdated ports:
sudo port -v selfupdate
sudo port upgrade outdated

Varnish DAEMON_OPTS Options Errors

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.