Need help translating a Make File into Meson Build File for Vala - gtk

I am working on an Application in Vala. I need to use both webkit2gtk-web-extension-4.0 and webkit2gtk-4.0 in an single project.
I am following the example from -
https://github.com/rschroll/webkitdom/tree/extension
The Make File from the example is as follows:
PKGS=--pkg gtk+-3.0 --pkg libsoup-2.4
EXEC=dom-test
SOURCES=dom-test.vala custom-web-view.vala
LIB_BASE=dom-server
LIB_SOURCES=$(LIB_BASE).vala
LIBRARY=$(LIB_BASE).so
# If you have webkit2gtk-4.0 installed, you will need a Vala from git
# version 6a1a1ab1 (2014/10/16) or later, in order to have the fixed
# .vapi files.
#WEBKIT_VAPI=--pkg webkit2gtk-4.0
#WEBKIT_EXT_VAPI=--pkg webkit2gtk-web-extension-4.0
# Otherwise, use the -3.0 versions included here
WEBKIT_VAPI=--vapidir=. --pkg webkit2gtk-3.0
WEBKIT_EXT_VAPI=--vapidir=. --pkg webkit2gtk-web-extension-3.0 -X -I/usr/include/webkitgtk-3.0
all: $(EXEC) $(LIBRARY)
$(EXEC): $(SOURCES)
valac $(WEBKIT_VAPI) $(PKGS) $^
$(LIBRARY): $(LIB_SOURCES)
valac $(WEBKIT_EXT_VAPI) $(PKGS) --library=$(LIB_BASE) -X -fPIC -X -shared -o $# $^
clean:
rm $(EXEC) $(LIBRARY)
With Meson Build system, I tried to create a subproject with the shared library and link the shared library in the main project. But I am getting the error
DOMServer.vala:1.1-1.10: error: The root namespace already contains a definition for `WebKit'
The main project meson.build file as follows:
project('com.linappfoundry.athmanam', ['c', 'vala'])
domserver_proj = subproject('DOMServer')
domserver_lib = domserver_proj.get_variable('domserver_lib')
cc = meson.get_compiler('c')
m_dep = cc.find_library('m', required : false)
executable(
meson.project_name(),
'AthmanamApp.vala',
'Widgets/MainWindow.vala',
'Widgets/PoemParserWebView.vala',
dependencies: [
dependency('gtk+-3.0'),
dependency('glib-2.0'),
dependency('libsoup-2.4'),
dependency('webkit2gtk-4.0'),
dependency('json-glib-1.0'),
dependency('libxml-2.0'),
m_dep
],
link_with: [domserver_lib],
install: true
)
And subproject's meson.build file is as follows:
project('com.linappfoundry.athmanam.DOMServer', ['c', 'vala'])
domserver_lib = shared_library(
'com.linappfoundry.athmanam.DOMServer',
'src/DOMServer.vala',
dependencies: [
dependency('glib-2.0'),
dependency('gtk+-3.0'),
dependency('libsoup-2.4'),
dependency('webkit2gtk-web-extension-4.0')
],
install: true
)
I am not sure what I am doing wrong here, as I am new to both Vala and Meson.

The error
DOMServer.vala:1.1-1.10: error: The root namespace already contains a definition for `WebKit'
is from the Vala compiler and is saying there is already a definition of Webkit in the global namespace. The error could be as simple as using a keyword with the wrong case, e.g. Using Webkit; when it should be using Webkit;.
Webkit is defined as a namespace in the global (root) namespace and that is done in the VAPI file. Try and find where it is being redefined as something else.

Related

Yocto rust recipe also produces -native output that needs packaging

I tried this approach on hardknott but I couldn't get it to work recipe also produces -native output that needs packaging
It is a rust recipe that generates an x86_64 app which I would like to package the right way in sdk, so that it can be used.
I can separate the main package to -native-bin, and I see it in the recipe-sysroot, but I can't get it to populate the recipe-sysroot of the workdir of the file when building the -native-helper recipe. And I suspect the reason is that I get an error that the main recipe for x86_64 can't be found?
ERROR: Manifest xxxxxx.populate_sysroot not found in vs_imx8mp cortexa53 armv8a-crc armv8a aarch64 allarch x86_64_x86_64-nativesdk (variant '')?
So any helpful information would be appreciated!
Hacked like this:
Recipe.bb:
do_install_append() {
# Set permision without run flag so that it doesn't fail on checks
chmod 644 ${D}/usr/bin/#RECIPE#-compiler
}
# #RECIPE# generates a compiler during the target generation step
#separate this to the -native-bin package, and skip the ARCH checks
#also in the image file for stations_sdk move the app to right dir and add execute flag
PACKAGES_prepend = "${PN}-native-bin "
PROVIDES_prepend = "${PN}-native-bin "
INSANE_SKIP_${PN}-native-bin = "arch"
FILES_${PN}-native-bin = "/usr/bin/#RECIPE#-compiler"
SYSROOT_DIRS += "/"
Image.bb:
# #RECIPE# produces a compiler that is produced as a part of the target generation
#so we use the recipe and hack it to supply the -compiler as part of the
#host binaries
TOOLCHAIN_TARGET_TASK_append = " #RECIPE#-native-bin"
do_fix_#RECIPE#() {
mv ${SDK_OUTPUT}/${SDKTARGETSYSROOT}/usr/bin/#RECIPE#-compiler ${SDK_OUTPUT}/${SDKPATHNATIVE}/usr/bin/#RECIPE#-compiler
chmod 755 ${SDK_OUTPUT}/${SDKPATHNATIVE}/usr/bin/#RECIPE#-compiler
}
SDK_POSTPROCESS_COMMAND_prepend = "do_fix_#RECIPE#; "
This produces at the end the binary in the right directory

Compiling Boost.Python toy example fails: ''error: expected unqualified-id before ‘%’ token %%bp_module"

I'm trying to compile a toy example using Boost.Python. I can compile the "quickstart" example.
However when I try to compile this toy example smoke_test.cpp:
%%bp_module smoke_test
#include <boost/python.hpp>
int test() {return 42; }
BOOST_PYTHON_MODULE(smoke_test)
{
boost::python::def("test",test);
}
and smoke_test.py:
import smoke_test
smoke_test.test()
using this Jamfile:
import python ;
import testing ;
project quickstart
: requirements
<location>.
;
# Declare a Python extension called hello.
python-extension extending : smoke_test.cpp ;
I get the following error:
smoke_test.cpp:1:1: error: expected unqualified-id before ‘%’ token
%%bp_module smoke_test
^
Does anyone know whats going wrong? I assume my Jamfile is incorrect but I'm not sure how to fix it.
I'm using boos 1.63.0 and python 2.7.
I guess the %%bp_module smoke_test line was false as mentioned by #doqtor. This was probably a toy example made for ipython notebook only. Although I couldn't figure out how to use bjam and Jamfiles to compile the code, I'm still now able to compile with this minimal Makefile example using my Ubuntu 14.04 system boost version (1.54.0):
PYTHON_VERSION = 2.7
PYTHON_INCLUDE = /usr/include/python$(PYTHON_VERSION)
# location of the Boost Python include files and library
BOOST_INC = /usr/include
BOOST_LIB = /usr/lib
# compile mesh classes
TARGET = smoke_test
$(TARGET).so: $(TARGET).o
g++ -shared -Wl,--export-dynamic $(TARGET).o -L$(BOOST_LIB) -lboost_python -L/usr/lib/python$(PYTHON_VERSION)/config -lpython$(PYTHON_VERSION) -o $(TARGET).so
$(TARGET).o: $(TARGET).cpp
g++ -I$(PYTHON_INCLUDE) -I$(BOOST_INC) -fPIC -c $(TARGET).cpp

Control mex link options with g++ from command line

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)

How can I use an Ada module in a Perl program using XS?

I started learning Ada recently and knowing that Ada and C object files can be linked together to build a multilingual program or library, is it possible to call Ada code from Perl using XS?
Yes!
In fact, any language that can be called from C can be used from Perl using XS. Here's a solution to how to do it with an Ada module and ExtUtils::MakeMaker.
Setting things up
Module tree
Let's start by creating a module tree using h2xs:
$ h2xs -A -n MyAdaModule
Then let's create a subdirectory to hold our Ada files:
$ cd MyAdaModule
$ mkdir src
Here is the module's specification: src/hello.ads
procedure hello;
... and the body: src/hello.adb
with Ada.Text_IO;
use Ada.Text_IO;
procedure hello is
begin
Put_Line("Hi from Ada!");
end;
Don't forget to update the MANIFEST.
Writing the XS file
Let's write the body of MyAdaModule.xs now. It's pretty much like using a function from a C library:
#define PERL_NO_GET_CONTEXT
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
#include "ppport.h"
extern void adainit();
extern void adafinal();
MODULE = MyAdaModule PACKAGE = MyAdaModule
void say_hello()
CODE:
adainit();
hello();
adafinal();
From the gnat documentation we know that we need to call adainit() and adafinal() to initialise and then clean up. These calls surround hello() here but they would probably be in a better place in some other function in your XS file. They would then be called from a BEGIN and END block in your Perl module.
Time to compile!
Ada library
First, we don't want to delegate all the magic linking and binding to MakeMaker so let's create a makefile in the src/ directory that will compile our Ada code into a static library.
To make this library, hello.a, we just have to follow the gnat documentation:
use gnatmake -c to generate a hello.ali and a hello.o;
use hello.ali with gnatbind with the -n switch. This will generate b~hello.adb and b~hello.ads which contain binding code;
compile b~hello.adb into an object file: b~hello.o.
group hello.o and b~hello.o together into an archive with ar
So, in short, we will use this makefile:
all: hello.a
hello.a: hello.o b~hello.o
ar rcs $# $^
hello.o: hello.adb hello.ads
gnatmake -c -o $# $<
b~hello.o: b~hello.adb b~hello.ads
gnatmake -c -o $# $<
b~hello.adb: hello.ali
gnatbind -n $<
hello.ali: hello.o
clean:
rm -rf *.o *.ali *.a b~*
Don't forget to update the MANIFEST.
Makefile.PL
Finally, the MakeFile.PL file needs some editing. It has to call the above makefile to build our library and then use it in the final linking phase. This is done by setting MYEXTLIB to src/hello.a and by adding a rule in the postamble section.
In our case, we also need to link with libgnat (for Ada.Text_IO) which should reside somewhere on your system. This is done by editing LIBS. In this example the path is hardcoded but you should probably figure out a more portable way to find libgnat.
use 5.018001;
use ExtUtils::MakeMaker;
# See lib/ExtUtils/MakeMaker.pm for details of how to influence
# the contents of the Makefile that is written.
WriteMakefile(
NAME => 'MyAdaModule',
VERSION_FROM => 'lib/MyAdaModule.pm', # finds $VERSION
PREREQ_PM => {}, # e.g., Module::Name => 1.1
($] >= 5.005 ? # Add these new keywords supported since 5.005
(ABSTRACT_FROM => 'lib/MyAdaModule.pm', # retrieve abstract from module
AUTHOR => 'A. U. Thor <author#nonet>') : ()),
DEFINE => '', # e.g., '-DHAVE_SOMETHING'
INC => '-I.', # e.g., '-I. -I/usr/include/other'
LIBS => ['-L/usr/lib/gcc/i686-pc-linux-gnu/4.8.2/adalib/ -lgnat'],
MYEXTLIB => 'src/hello.a',
);
sub MY::postamble {
join("\n",
"\$(MYEXTLIB)::",
"\tmake -C src/",
"",
"clean::",
"\tmake -C src/ clean",
);
}
Now try
$ perl Makefile.PL
$ make
$ make test
And surprise: the test doesn't pass! The hello() symbol doesn't exist. Inspecting the MyAdaLib.so generated by make with the nm tool reveals that some symbols have been renamed. In my case, they were prefixed with _ada_. So I'd have to call _ada_hello() instead of hello(). This can be corrected in src/ada.ads using the Export pragma:
pragma Export
(Convention => C,
Entity => hello,
External_Name => "hello" );
From what I understood, this should be done for all public symbols as it ensures the representation of types, records, etc, is understood from a C program.
Now, you should be able to call hello() from the XSUB. Enjoy!

make error when cross compile Perl for ARM

I have successfully configure perl for cross comile by using configure options:
./Configure -des -Dusecrosscompile \
-Dtargethost=172.17.185.91 \
-Dtargetdir=/home/perl/ \
-Dtargetuser=root \
-Dtargetarch=arm-linux \
-Dcc=arm-linux-gcc \
-Dusrinc=/opt/Mozart_Toolchain/arm-eabi-uclibc/include/ \
-Dincpth=/opt/Mozart_Toolchain/arm-eabi-uclibc/include/ \
-Dlibpth=/opt/Mozart_Toolchain/arm-eabi-uclibc/lib/
And the configure script tell me "Now you must run 'make'." But I encounter such as error when I make:
`sh cflags "optimize='-O2'" miniperlmain.o` miniperlmain.c
CCCMD = arm-linux-gcc -DPERL_CORE -c -DOVR_DBL_DIG=14 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -Wall
In file included from perl.h:38,
from miniperlmain.c:40:
config.h:4425:12: error: operator '==' has no left operand
In file included from miniperlmain.c:40:
perl.h:713:14: error: operator '>=' has no left operand
... ...
In config.h, some macro is left blank, for example:
#define INTSIZE /**/
#define LONGSIZE /**/
#define SHORTSIZE /**/
... much more ...
And I think it is the undefined macro result in the make error. I have no idea how to fix it. Why the macro is blank even if successfully configure?
Are there some guides to cross compile Perl?
There is a Cross directory that features a README file that includes the following instructions for arm-linux:
1) You should be reading me (README) in perl-5.x.y/Cross
2) Make sure you are in the Cross directory.
3) Edit the file 'config' to contain your target platform information.
4) make patch ## This will patch the existing source-tree.
5) make perl ## Will make perl
(Read the whole thing.)
I got the easiest way to cross compile Perl for arm-linux.Please refer to Cross-compiling perl. It's a great work! It saved my life.
Just according to instructions that give, you can get what you want. You may encounter such error when 'make':
pp_sys.c:78: error: non-thread-local declaration of 'h_errno' follows thread-local declaration
Simply comment that line.
Enjoy it!