I have a .spec file to build rpm for Fedora, CentOS and Oracle Linux. I need to install a post-uninstall trigger for the kernel package. To achieve that for Oracle Linux, I need to put something like this in my spec file:
%triggerpostun -- kernel-uek
%(cat %{SOURCE1001})
On CentOS, the package is called kernel, and on Fedora it is called kernel-core. My question is, how do I specify the trigger in my spec file in a portable way (so that it works on all of these target platforms), without any duplication?
EDIT: Some information about what I have tried - I tried putting the following in my spec file:
%if 0%{?fedora}
%triggerpostun -- kernel-core
%else
%if 0%{?ol7}
%triggerpostun -- kernel-uek
%else
%triggerpostun -- kernel
%endif
%endif
%(cat %{SOURCE1006})
But on CentOS, this gives me a trigger like this:
triggerpostun scriptlet (using /bin/sh) -- kernel-uek
for filename in /boot/*.ksplice-updates*; do
if [[ -h $filename && ! -e $filename ]]; then
rm $filename
fi
done
which is wrong because the correct package name on CentOS is kernel.
I am complete noob to packaging, so let me know if you need more context to provide suggestion.
I assume the multiple %else are causing problems. I would define the conditions this way:
%if 0%{?fedora}
%define kernelpkgname kernel-core
%endif
%if 0%{?ol7}
%define kernelpkgname kernel-uek
%endif
%if 0%{?rhel} >= 6
%define kernelpkgname kernel
%endif
Then use kernelpkgname variable in the triggerpostun.
%postun
....
%triggerpostun -- %{kernelpkgname}
cat %{SOURCE1006}
while I can use several turtle scripts in the same directory
(have eg. pretty.hs and srv.hs interpreted), I learned that I can have
only have one of them compiled eg. with
ghc -no-user-package-db -package-db .cabal-sandbox/*-packages.conf.d -O2 -threaded -outputdir=. -o srv srv.hs
as this implicitly builds Main.o and Main.hi as well, and and srv and pretty would
need two different object files, obviously.
What's the story of Turtle and the Main module anyway: wouldn't it
have been nicer, if one could use (and thus choose) a module name, like so
Module Whatever
import Turtle
I tried to compile the .o files separatly, but with no luck:
$ ghc -no-user-package-db -package-db .cabal-sandbox/*-packages.conf.d -O2 -threaded -outputdir=. -c -o MainPretty.o pretty.hs
no complaints so far, but then:
$ ghc -no-user-package-db -package-db .cabal-sandbox/*-packages.conf.d -O2 -threaded -outputdir=. -o pretty MainPretty.o
MainPretty.o: In function `rdyO_info':
(.text+0x40e): undefined reference to `transzuGZZTjP9K5WFq01xC9BAGQpF_ControlziMonadziIOziClass_zdfMonadIOIO_closure'
MainPretty.o: In function `rdyQ_info':
(.text+0x4d6): undefined reference to `transzuGZZTjP9K5WFq01xC9BAGQpF_ControlziMonadziIOziClass_zdfMonadIOIO_closure'
MainPretty.o: In function `cfxy_info':
(.text+0x712): undefined reference to `optpazuFpNJ7fLofFNEy3rK4ZZnBoD_OptionsziApplicativeziTypes_AltP_con_info'
MainPretty.o: In function `cfxy_info':
(.text+0x72e): undefined reference to `systezu0e3pMPmZZzzix21iFp2U03Lc_FilesystemziPathziRules_posixFromText_closure'
MainPretty.o: In function `cfyR_info':
(.text+0x92a): undefined reference to `optpazuFpNJ7fLofFNEy3rK4ZZnBoD_OptionsziApplicativeziTypes_AltP_con_info'
and so on...
Is it possible nevertheless to compile two different turtle scripts in the same dir? how?
Thanks.
Ah, to answer my own question: I saw that I just have to remove these Main.o/Main.hi files after compiling (to have different one created anew then),
like so:
ghc -no-user-package-db -package-db .cabal-sandbox/*-packages.conf.d -O2 -threaded -outputdir=. -o pretty pretty.hs
rm -f Main.o Main.hi
Sorry for the noise
I'm trying to link a library using mex from command line, or more exactly, from a makefile. I do this from a Makefile which I post here:
BDDM_MATLAB = #matlabhome#
MEXCC = $(BDDM_MATLAB)/bin/mex
MEXFLAGS = -v -largeArrayDims -O
MEXEXT = mexa64
TDIR = $(abs_top_srcdir)/test
IDIR = $(abs_top_srcdir)/src
LDIR = $(abs_top_srcdir)/lib
LOP1 = $(CUDA_LDFLAGS) $(LIBS)
SOURCES := $(wildcard *.cpp)
OBJS = $(SOURCES:.cpp=.o)
mTESTS = $(addprefix $(TDIR)/, $(SOURCES:.cpp=.$(MEXEXT)))
all: $(TDIR) $(mTESTS)
$(OBJS) : %.o : %.cpp
$(MEXCC) $(MEXFLAGS) -c -outdir ./ -output $# $(CUDA_CFLAGS) -I$(IDIR) CFLAGS="\$$CFLAGS -std=c99" $^
$(mTESTS) : $(TDIR)/%.$(MEXEXT) : %.o
$(MEXCC) $(MEXFLAGS) -L$(LDIR) -outdir $(TDIR) $^ $(LOP1) -lmpdcm LDFLAGS="-lcudart -lcuda"
.PHONY = $(TDIR)
$(TDIR):
$(MKDIR_P) $#
clean:
$(RM) *.o
libmpdcm is a static library that includes calls to two shared libraries libcuda and libcudart. My environment has
export LD_LIBRARY_PATH=/usr/local/cuda-7.0/lib64:$LD_LIBRARY_PATH:
My make rule produces
/usr/local/MATLAB/R2014a/bin/mex -v -largeArrayDims -O -L/home/eaponte/projects/test_cpp/lib -outdir /home/eaponte/projects/test_cpp/test test_LayeredEEG.o -L/usr/local/cuda/lib64 -lcudart -lcuda -lmpdcm LDFLAGS="-lcudart -lcuda"
This produces the following g++ command:
/usr/bin/gcc -lcudart -lcuda -shared -O -Wl,--version-script,"/usr/local/MATLAB/R2014a/extern/lib/glnxa64/mexFunction.map" test_LayeredEEG.o -lcudart -lcuda -lmpdcm -L/home/eaponte/projects/test_cpp/lib -L/usr/local/cuda/lib64 -L"/usr/local/MATLAB/R2014a/bin/glnxa64" -lmx -lmex -lmat -lm -lstdc++ -o /home/eaponte/projects/test_cpp/test/test_LayeredEEG.mexa64
The problem is that afterwards I get a linking error in Matlab:
Invalid MEX-file '/home/eaponte/projects/test_cpp/test/test_Fmri.mexa64': /home/eaponte/projects/test_cpp/test/test_Fmri.mexa64: undefined symbol: cudaFree
I know that the solution is simply to put the cuda libraries at the end of the g++ command
/usr/bin/gcc -lcudart -lcuda -shared -O -Wl,--version-script,"/usr/local/MATLAB/R2014a/extern/lib/glnxa64/mexFunction.map" test_LayeredEEG.o -lmpdcm -L/home/eaponte/projects/test_cpp/lib -L/usr/local/cuda/lib64 -L"/usr/local/MATLAB/R2014a/bin/glnxa64" -lmx -lmex -lmat -lm -lstdc++ -lcudart -lcuda -o /home/eaponte/projects/test_cpp/test/test_LayeredEEG.mexa64
How can achieve that running mex from command line (or from a Makefile)?
Just to illuminate the problem and solution and offer some help in avoiding the like:
The fundamental rule of linkage with the GNU linker
that your problem makefile transgressed is: In the commandline sequence of entities to be linked, ones that need symbol definitions
must appear before the ones that provide the definitions.
An object file (.o) in the linkage sequence will be incorporated entire in the output executable,
regardless of whether or not it defines any symbols that the executable uses. A library
on the other hand, is merely examined to see if it provides any definitions for symbols
that are thus-far undefined, and only such definitions as it provides are linked into in
the executable (I am simplifying somewhat). Thus, linkage doesn't get started until some object file is seen,
and any library must appear after everything that needs definitions from it.
Breaches of this principle usually arise from inept bundling of some linker flag-options
and some library-options together into a make-variable and its placement in the linkage recipe,
with the result that the bundled options are interpolated at a position that is valid for
the flags but not valid for libraries. This was so in your problem makefile, with LOP1 the
bad bundle.
In the typical case, the bundling causes all of the libraries to be placed before all the object files,
and never mentioned again. So the object files yield undefined symbol errors, because the libraries
they require were seen by the linker before it had discovered any undefined symbols, and were ignored.
In your untypical case, it resulted in libcudart and libcuda being seen later than your only
object file test_LayeredEEG.o - which however required no symbols from them - but earlier than
the only thing that did require symbols from them, the library libmpdcm. So they were ignored,
and you built a .mex64 shared library that had not been linked with them.
Long ago - pre-GCC 4.5 - shared libraries (like libcudart and libcuda) were exempt
from the requirement that they should be needed, at the point when the linker sees them,
in order to be linked. They were linked regardless, like object files, and the belief that
this is so has not entirely died out. It is not so. By default, shared libraries and
static libraries alike are linked if and only if needed-when-seen.
To avoid such traps it is vastly helpful to understand the canonical nomenclature of
the make variables involved in compilation and linkage and their semantics, and
their canonical use in compilation and linkage recipes for make. Mex is a
manipulator of C/C++/Fortran compilers that adds some commandline options of its own:
for make purposes, it is another compiler. For the options that it inherits from and
passes to the underlying compiler, you want to adhere to the usage for that compiler in make recipes.
These are the make variables most likely to matter to you and their meanings:
CC = Your C compiler, e.g. gcc
FC = Your Fortran compiler, e.g. gfortran
CXX = Your C++ compiler, e.g. g++.
LD = Your linker, e.g. ld. But you should know that only for specialized uses
should the linker be directly invoked. Normally, the real linker is invoked on your
behalf by the compiler. It can deduce from the options that you pass it whether you
want compiling done or linking done, and will invoke the appropriate tool. When you
want linking done, it will quietly augment the linker options that you pass with
additional ones that it would be very tiresome to specify, but which ensure
that the linkage acquires all the the correct flags and libraries for the language of the
program you are linking. Consequently almost always, specify your compiler as your
linker.
AR = Your archiving tool (static library builder)
CFLAGS = Options for C compilation
FFLAGS = Options for Fortran compilation
CXXFLAGS = Options for C++ compilation
CPPFLAGS = Options for the C preprocessor, for any compiler that uses it. Avoid the common mistake of writing CPPFLAGS when you mean CXXFLAGS
LDFLAGS = Options for linkage, N.B. excluding library options, -l<name>
LDLIBS = Library options for linkage, -l<name>
And the canonical make rules for compiling and linking:
C source file $< to object file $#:
$(CC) $(CPPFLAGS) $(CFLAGS) -c $# $<
Free-from Fortran file $< to object file $#, with preprocessing:
$(FC) $(CPPFLAGS) $(FFLAGS) -c $# $<
(without preprocessing, remove $(CPPFLAGS))
C++ source file $< to object file $#:
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $# $<
Linking object files $^ into an executable $#:
$(<compiler>) $(LDFLAGS) -o $# $^ $(LDLIBS)
If you can as much as possible write makefiles so that a) you have assigned the right options to the right variables from
this glossary, and b) used the canonical make recipes, then your path will be much smoother.
And BTW...
Your makefile has the following bug:
.PHONY = $(TDIR)
This is apparently an attempt to make $(TDIR) a phony target,
but the syntax is wrong. It should be:
.PHONY: $(TDIR)
what the assignment does is simply create a make variable called, .PHONY with the value of $(TDIR),
and does not make $(TDIR) a phony target.
Which is fortunate, because $(TDIR) is your output directory and not a phony
target.
You wish to ensure that make creates $(TDIR) before you need to output anything into
it, but you do not want it to a normal prequisite of those artefacts, which would oblige
make to rebuild them whenever the timestamp of $(TDIR) was touched. That is presumably
why you thought to make it a phony target.
What you actually want $(TDIR) to be is an order-only prerequsite
of the $(mTESTS) that will be output there. The way to do that is to amend the $(mTESTS) rule to be:
$(mTESTS) : $(TDIR)/%.$(MEXEXT) : %.o | $(TDIR)
This will cause $(TDIR) to be made, if needed, before $(mTESTS) is made, but
nevertheless $(TDIR) will not be considered in determining whether $(mTESTS) does
need to be made.
On the other hand, the targets all and clean are phony targets: no such artefacts
are to be made, so you should tell make so with:
.PHONY: all clean
As pointed out in the comments, the problem was in the order of the dynamic libraries in the compilation flags. After searching the reason for this I found in SO that static libraries need to be linked taking into account the order of dependency. In my case, the library libmpdc had dependencies on libcuda and libcudart but was on the left. The solution is to swap the order in the makefile from:
$(mTESTS) : $(TDIR)/%.$(MEXEXT) : %.o
$(MEXCC) $(MEXFLAGS) -L$(LDIR) -outdir $(TDIR) $^ $(LOP1) -lmpdcm LDFLAGS="-lcudart -lcuda"
to
$(mTESTS) : $(TDIR)/%.$(MEXEXT) : %.o
$(MEXCC) $(MEXFLAGS) -L$(LDIR) -outdir $(TDIR) $^ -lmpdcm $(LOP1)
To all,
I'm trying to run a makefile using the 'mex' command through Matlab. However,
when I try to run my test .m script using 'compile_mex;" I get the following error:
>> compile_mex
xcodebuild: error: SDK "macosx10.7" cannot be located.
xcrun: error: unable to find utility "clang++", not a developer tool or in PATH
mex: compile of ' "mex/perform_nlmeans_mex.cpp"' failed.
I've read through a couple of sources that a shell script may need to be written
to physically add the clang++ utility through a library that I need to import into
Matlab directly. Does anyone know how to fix/perform this? A sample or example shell
script and directions on how to use that script within or in coordination with
Matlab would be great if anyone can provide me this. Thanks!
A temporary workaround is given here. Effectively it amounts to getting MATLAB to use a different SDK (as the 10.7 SDK is removed in Mavericks). From the link:
Just for clarity in case someone else runs into the same issue, I
changed four lines in mexopts.sh:
# CC='xcrun -sdk macosx10.7 clang'
CC='xcrun -sdk macosx10.8 clang'
# MW_SDK_TEMP="find `xcode-select -print-path` -name MacOSX10.7.sdk"
MW_SDK_TEMP="find `xcode-select -print-path` -name MacOSX10.8.sdk"
# MACOSX_DEPLOYMENT_TARGET='10.7'
MACOSX_DEPLOYMENT_TARGET='10.8'
# CXX='xcrun -sdk macosx10.7 clang++'
CXX='xcrun -sdk macosx10.8 clang++'
I also had to do "mex -setup" from inside matlab in order to copy
mexopts.sh to my user directory.
When I did this change I directly edited ~/.matlab/R2013a/mexopts.sh rather than .matlab/R2013a/mexopts.sh – I felt this was slightly safer. It also removes the requirement to rerun mex -setup, but of course this means that the file can be overwritten.
For 10.9:
CC='xcrun -sdk macosx10.9 clang'
MW_SDK_TEMP="find `xcode-select -print-path` -name MacOSX10.9.sdk"
MACOSX_DEPLOYMENT_TARGET='10.9'
CXX='xcrun -sdk macosx10.9 clang++'
I'm trying to build a very simple PostgreSQL client in C over Cygwin.
Here's what I've done so far:
I've downloaded the PostgreSQL source code version 9.1.2 (to match the same version that is running on my server)
I've configured and compiled the source code from Cygwin. The compilation seemed to go smoothly.
From what I can tell, the header files are in:
/cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq, and
/cygdrive/c/workspace/src/postgresql-9.1.2/src/include
The libraries are in:
/cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq
From here, I compiled and linked the client program using the makefile below:
testlibpq: testlibpq.c
gcc -o testlibpq -I /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq -I /cygdrive/c/workspace/src/postgresql-9.1.2/src/include -L /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq testlibpq.c -Bstatic -lpq
The compilation and the linking succeeded without errors or warnings.
However, when I try to run the program, I get the following error:
$ ./testlibpq
/cygdrive/c/Users/dleclair/Dropbox/denis/src/testlibpq/testlibpq.exe: error while loading shared libraries: cygpq.dll: cannot open shared object file: No such file or directory
I haven't figured out how to fix this. Any pointers would be greatly appreciated.
Oh, one more thing, I found the folder that cygpq.dll was sitting in and set my LD_LIBRARY_PATH to point to it but it still gave me the same result.
dleclair#dleclair-win7l ~/Dropbox/denis/src/testlibpq
$ ls /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq
bcc32.mak encnames.o fe-connect.o fe-misc.o fe-protocol3.o ip.o libpq-events.c md5.c pgstrcasecmp.c pqsignal.c thread.o
blibpqdll.def exports.txt fe-exec.c fe-print.c fe-secure.c libpq.a libpq-events.h md5.o pgstrcasecmp.o pqsignal.h wchar.c
chklocale.c fe-auth.c fe-exec.o fe-print.o fe-secure.o libpq.rc.in libpq-events.o nls.mk po pqsignal.o wchar.o
chklocale.o fe-auth.h fe-lobj.c fe-protocol2.c inet_net_ntop.c libpqddll.def libpq-fe.h noblock.c pqexpbuffer.c pthread-win32.c win32.c
cygpq.dll fe-auth.o fe-lobj.o fe-protocol2.o inet_net_ntop.o libpq-dist.rc libpq-int.h noblock.o pqexpbuffer.h README win32.h
encnames.c fe-connect.c fe-misc.c fe-protocol3.c ip.c libpqdll.def Makefile pg_service.conf.sample pqexpbuffer.o thread.c win32.mak
dleclair#dleclair-win7l ~/Dropbox/denis/src/testlibpq
$ echo $LD_LIBRARY_PATH
/cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq
dleclair#dleclair-win7l ~/Dropbox/denis/src/testlibpq
Normally on unix/linux systems after building the source a make install is done which copies the headers to standard locations like /usr/local/include and /usr/local/lib. You may have to do that on cygwin to to get the DLL in the search path.
Or you can just locate the DLL yourself and put it on the search path or in the same folder as your executable.