Qtcreator specify lib name - qt-creator

I am trying to create a python extension in c++ using boost.Python.
I use qtcreator as an IDE.
my .pro file is:
TEMPLATE = lib
CONFIG += plugin
CONFIG -= app_bundle
CONFIG -= qt
SOURCES += \
bmodule.cpp \
entry.cpp
QMAKE_CXXFLAGS += -std=c++11
INCLUDEPATH += /usr/include/boost /usr/include/python2.7
DEFINES += BOOST_PYTHON_DYNAMIC_LIB
LIBS += -L/usr/local/lib -L/usr/lib/python2.7 -lpython2.7 -lboost_python
TARGET = bmodule
HEADERS += \
entry.h
It works but it creates a so file named libbmodule.
I want it to produce one called bmodule.so .
what option I have to add to the pro file?
Currently I am doing:
QMAKE_PRE_LINK = rm -f bmodule.so
QMAKE_POST_LINK = cp libbmodule.so bmodule.so && rm libbmodule.so
QMAKE_DISTCLEAN += bmodule.so
but I do not like it

CONFIG += no_plugin_name_prefix
Add this to your .pro file somewhere.

Related

Execute a cross-compiled binary for ARM on x86 host machine within Yocto Recipe

I have a Makefile where within:
TARGETDIR=../rel/$(PLATFORM)
ANALYZER=$(TARGETDIR)/analyzer
TARGETS=$(ANALYZER)
XMLFILE=pgns.xml
JSONFILE=pgns.json
all: $(TARGETS)
$(ANALYZER): analyzer.c pgn.c analyzer.h pgn.h ../common/common.c ../common/common.h Makefile
$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -o $(ANALYZER) -I../common pgn.c analyzer.c ../common/common.c $(LDLIBS$(LDLIBS-$(#)))
json: $(ANALYZER) pgns2json.xslt
$(ANALYZER) -explain-xml >$(XMLFILE) && xsltproc pgns2json.xslt $(XMLFILE) >$(JSONFILE)
$(ANALYSER) gets compiled and is stored in TARGETDIR. Now in json the analyzer binary is called which provides
| /bin/sh: ../rel/linux-x86_64/analyzer: cannot execute binary file: Exec format error
because upon file analyzer it show the file as ELF 32-bit file. I understand incompatibility here.
This has been addressed in the my Previous SE Query.
Since I cannot get around this issue; I was thinking of using the json call in a postinstall script in my Recipe.
But I cannot wrap my head around it. These are the steps I have drawn up:
I modify the Makefile which removes json
Should I add DEPENDS = "libxslt libxml2 ?
Should I add RDEPENDS_{PN} = "bash" to execute the command for json?
how should the post-install look like for the recipe?
The Recipe:
SUMMARY = "CANBOAT"
SECTION = "base"
LICENSE = "GPLv3"
#DEPENDS = "libxml2 libxsl"
LIC_FILES_CHKSUM = "file://GPL;md5=05507c6da2404b0e88fe5a152fd12540"
S = "${WORKDIR}/git"
SRC_URI = "git://github.com/canboat/canboat.git;branch=${SRCBRANCH}"
SRCBRANCH = "master"
SRCREV = "93b2ebfb334d7a9750b6947d3a4af9b091be2432"
EXTRA_OEMAKE = "'CC=${CC}' 'AR=${AR}'"
do_compile() {
oe_runmake
}
do_install() {
oe_runmake install
}
#post_install() { # here? what will be the structure}
analyzer is a tool that is used to generate some artifacts and is not necessarily needed to be compiled for target in a cross compile environment , rather it needs a platform to run (build host) and input file.
SUMMARY = "CANBOAT"
SECTION = "base"
LICENSE = "GPLv3"
DEPENDS += "libxslt-native canboat-native"
LIC_FILES_CHKSUM = "file://GPL;md5=05507c6da2404b0e88fe5a152fd12540"
SRC_URI = "git://github.com/canboat/canboat.git;branch=${SRCBRANCH} \
file://0001-Do-not-use-root-user-group-during-install.patch \
file://0001-Define-ANALYZEREXEC.patch \
file://0001-use-php-instead-of-php5.patch \
"
SRCBRANCH = "master"
SRCREV = "93b2ebfb334d7a9750b6947d3a4af9b091be2432"
S = "${WORKDIR}/git"
PREFIX ?= "${root_prefix}"
#PREFIX_class-native = "${prefix}"
EXTRA_OEMAKE_append_class-target = " ANALYZEREXEC=analyzer "
do_compile() {
oe_runmake
}
do_install() {
oe_runmake DESTDIR=${D} PREFIX=${root_prefix} EXEC_PREFIX=${exec_prefix} install
}
RDEPENDS_${PN}_append_class-target = " php-cli perl"
BBCLASSEXTEND = "native nativesdk"
The extra patches you need to cross compile canboat are here
0001-Define-ANALYZEREXEC.patch
0001-Do-not-use-root-user-group-during-install.patch
0001-use-php-instead-of-php5.patch

Is there a limit to the size of a variable in a makefile

I have been adding sources to the included makefile for a project. As is, right now it runs perfectly. But if I uncomment the two lines indicated in the code, make spits out the following error:
make: *** No rule to make target 'engine/obj/graphics/window.o', needed by 'lib/engine.a'. Stop.
I assume since it's just cutting off the start its something to with the length. If this is some limitation of the length of the variable is there any way around it?
CXX = g++
CXXFLAGS = -std=c++11 -g -Wall -Wextra
OUT_DIR=out
LIB_OUT_DIR=lib
APP_NAME=main
ENGINE_NAME=engine.a
EXECUTABLE=$(OUT_DIR)/$(APP_NAME)
ENGINE_LIB=$(LIB_OUT_DIR)/$(ENGINE_NAME)
ENGINE_OBJECT_DIR=engine/obj
ENGINE_HEADER_DIR=engine/include
ENGINE_SOURCE_DIR=engine/src
ENGINE_SHADER_DIR=engine/shaders
APP_OBJECT_DIR=app/obj
APP_SOURCE_DIR=app/src
ENGINE_OBJECTS = $(ENGINE_OBJECT_DIR)/graphics/window.o
ENGINE_OBJECTS += $(ENGINE_OBJECT_DIR)/graphics/shader_program.o
ENGINE_OBJECTS += $(ENGINE_OBJECT_DIR)/graphics/array.o
ENGINE_OBJECTS += $(ENGINE_OBJECT_DIR)/graphics/attribute_definition.o
ENGINE_OBJECTS += $(ENGINE_OBJECT_DIR)/graphics/abstract/buffer.o
ENGINE_OBJECTS += $(ENGINE_OBJECT_DIR)/graphics/simple_buffer.o
# ENGINE_OBJECTS += $(ENGINE_OBJECT_DIR)/graphics/instance_buffer.o
ENGINE_OBJECTS += $(ENGINE_OBJECT_DIR)/graphics/index_buffer.o
ENGINE_OBJECTS += $(ENGINE_OBJECT_DIR)/math/vec2.o
ENGINE_OBJECTS += $(ENGINE_OBJECT_DIR)/math/vec3.o
ENGINE_OBJECTS += $(ENGINE_OBJECT_DIR)/math/vec4.o
ENGINE_OBJECTS += $(ENGINE_OBJECT_DIR)/math/mat4.o
ENGINE_OBJECTS += $(ENGINE_OBJECT_DIR)/util/logging.o
ENGINE_SOURCES = $(ENGINE_SOURCE_DIR)/graphics/window.cpp
ENGINE_SOURCES += $(ENGINE_SOURCE_DIR)/graphics/shader_program.cpp
ENGINE_SOURCES += $(ENGINE_SOURCE_DIR)/graphics/array.cpp
ENGINE_SOURCES += $(ENGINE_SOURCE_DIR)/graphics/attribute_definition.cpp
ENGINE_SOURCES += $(ENGINE_SOURCE_DIR)/graphics/abstract/buffer.cpp
ENGINE_SOURCES += $(ENGINE_SOURCE_DIR)/graphics/simple_buffer.cpp
# ENGINE_SOURCES += $(ENGINE_SOURCE_DIR)/graphics/instance_buffer.cpp
ENGINE_SOURCES += $(ENGINE_SOURCE_DIR)/graphics/index_buffer.cpp
ENGINE_SOURCES += $(ENGINE_SOURCE_DIR)/math/vec2.cpp
ENGINE_SOURCES += $(ENGINE_SOURCE_DIR)/math/vec3.cpp
ENGINE_SOURCES += $(ENGINE_SOURCE_DIR)/math/vec4.cpp
ENGINE_SOURCES += $(ENGINE_SOURCE_DIR)/math/mat4.cpp
ENGINE_SOURCES += $(ENGINE_SOURCE_DIR)/util/logging.cpp
ENGINE_SHADERS = \
$(OUT_DIR)/vertexshader.glsl \
$(OUT_DIR)/fragmentshader.glsl
APP_OBJECTS = \
$(APP_OBJECT_DIR)/main.o
APP_SOURCES = \
$(APP_SOURCE_DIR)/main.cpp
ENGINE_CXX_LIBS=-Wl,-Bstatic -lGLEW -lglfw3 -pthread -Wl,-Bdynamic -lGL -lGLU -ldl -lX11 -lXi -lXxf86vm -lXrandr -lXcursor -lXinerama
APP_CXX_LIBS=-L$(LIB_OUT_DIR) -l:$(ENGINE_NAME)
.PHONY: all build clean engine app run
all: clean build run
clean:
rm -f $(OUT_DIR)/* $(LIB_OUT_DIR)/* $(ENGINE_OBJECTS) $(APP_OBJECTS)
build: engine app
run:
cd $(OUT_DIR) && \
./$(APP_NAME)
engine: $(ENGINE_LIB) $(ENGINE_SHADERS)
app: $(EXECUTABLE)
$(ENGINE_OBJECT_DIR)/%.o: $(ENGINE_SOURCE_DIR)/%.cpp $(ENGINE_SOURCES)
$(CXX) -I$(ENGINE_HEADER_DIR) -c -o $# $< $(CXXFLAGS)
$(ENGINE_LIB): $(ENGINE_OBJECTS)
ar rvs $# $(ENGINE_OBJECTS)
$(OUT_DIR)/%.glsl: $(ENGINE_SHADER_DIR)/%.glsl
cp -f $< $#
$(APP_OBJECT_DIR)/%.o: $(APP_SOURCE_DIR)/%.cpp $(APP_SOURCES)
$(CXX) -I$(ENGINE_HEADER_DIR) -c -o $# $< $(CXXFLAGS)
$(EXECUTABLE): $(APP_OBJECTS)
$(CXX) -o $# $^ $(APP_CXX_LIBS) $(ENGINE_CXX_LIBS)
There is no limit to the size of a variable in make (except for the amount of memory in your system). Your operating system will impose a maximum on the size of a command line that make can invoke, so if your variables are very large and you try to use them in a recipe it's possible the operating system will not allow it, but that's nothing to do with make and not the problem you're seeing here anyway.
I think the problem is that the file $(ENGINE_SOURCE_DIR)/graphics/instance_buffer.cpp either doesn't exist or can't be accessed for some reason.
This rule is very broken:
$(ENGINE_OBJECT_DIR)/%.o: $(ENGINE_SOURCE_DIR)/%.cpp $(ENGINE_SOURCES)
$(CXX) -I$(ENGINE_HEADER_DIR) -c -o $# $< $(CXXFLAGS)
By adding the $(ENGINE_SOURCES) here you're saying that if any source file changes, ALL of the object files must be rebuilt. I can't believe that's what you want (if you want to rebuild everything if any file changes you can just write a shell script that always rebuilds everything and you don't need make at all).
Not only that, but if make can't find or build ALL the source files, then this pattern rule won't match and make will keep looking to see if some other pattern rule will match. In this case there are no others, so make just says "hey, I don't know how to build the file" (in this case, the .../window.o file).
Also if you run make with debugging (make -d) you'll see the problem (although the output is voluminous so you'll probably need to redirect it to a file and examine with an editor or less or something that lets you search and page back and forth).
You should remove $(ENGINE_SOURCES) from this rule. Then likely make will fail with a more reasonable error, that it can't build .../instance_buffer.o.

Why is automake prefixing my object files with the package name?

In my src directory, I have source files such as cells.c. When I perform a compilation, the compiler prefixes the object file with the package name, so that it becomes neoleo-cells.o, for example. Why is it doing this, and how can I stop it? I don't think it's standard behaviour.
Here is Makefile.am:
#VPATH = $(srcdir) $(builddir)
GUI_SRCS =
GUI_LINK =
#GUI_DEFINES = -DX_DISPLAY_MISSING
GUI_DEFINES = -DHAVE_X
# Order of linking of libraries for Motif seems to be important
# I have decided to mandate the use of the Xbae library, rather than
# have it optional.
if UseMotif
GUI_SRCS += io-motif.c appres.c fallback.c oleo_icon.xpm
GUI_LINK += -lXm -lXt -lXbae
GUI_DEFINES += -DHAVE_MOTIF
endif
GUI_SRCS += io-x11.c xrdb.c
GUI_LINK += -lX11
YFLAGS = -d
EXTRA_DIST = $(srcdir)/neoleo.i
bin_PROGRAMS = neoleo
BUILT_SOURCES = getdate.c parse.c parse.h posixtm.c posixtm.h
#BUILT_SOURCES += neoleo_wrap.c
CLEANFILES = $(BUILT_SOURCES)
#lib_LTLIBRARIES = libneoleo.la
neoleo_CFLAGS = $(GUI_DEFINES) -Dmain0=main
neoleo_LDADD = -lm -lncurses -lpthread $(GUI_LINK)
#neoleo_LDFLAGS = -e main0
#neoleo_la_LDFLAGS = -module -avoid-version -shared
neoleo_SOURCES = afm.c args.c basic.c busi.c byte-compile.c cells.c cmd.c date.c decompile.c display.c \
epson.c eval.c font.c format.c forminfo.c funcs.c graph.c gsl.c hash.c help.c \
info.c init.c input.c \
io-headless.c io-curses.c io-edit.c io-term.c io-utils.c \
ir.c key.c legend.c line.c list.c lists.c mdi.c oleofile.c pcl.c plot.c \
postscript.c print.c prtext.c ref.c regions.c sc.c sort.c string.c stub.c sylk.c utils.c \
window.c \
defuns.c \
get_date.h getdate.y \
parse.y \
posixtm.y \
neoleo_swig.c \
mysql.c $(GUI_SRCS)
noinst_HEADERS = afm.h appres.h args.h basic.h byte-compile.h cell.h \
cmd.h decompile.h defun.h defuns.h display.h epson.h \
errors.h eval.h font.h format.h forminfo.h funcdef.h \
funcs.h global.h graph.h hash.h help.h info.h init.h \
input.h io-abstract.h io-headless.h io-curses.h io-edit.h \
io-generic.h io-motif.h io-term.h io-utils.h io-x11.h \
ir.h key.h line.h list.h lists.h mdi.h mysql.h node.h \
oleofile.h oleo_plot.h oleosql.h oleo_xb.h parse.h pcl.h \
posixtm.h postscript.h print.h proto.h prtext.h ref.h \
regions.h sc.h sciplot.h sciplotI.h sort.h stub.h stubs.h \
sylk.h sysdef.h userpref.h utils.h window.h \
neoleo_swig.h
# exclude these for now:
# plotter.c xbase.cpp
ref.o : parse.h
#neoleo_wrap.c : $(srcdir)/neoleo.i neoleo_swig.c neoleo_swig.h
# swig -tcl8 -o $# $<
This line causes the rename of the object files:
neoleo_CFLAGS = $(GUI_DEFINES) -Dmain0=main
If you have target-dependent compilation flags, Automake chooses different names for the resulting object files. This approach avoids clashes if there are multiple different targets that use the same sources but different flags.
Now, Automake could in theory notice that this isn't happening and not rename the object files. However, in practice most people don't care what the intermediate files are called, and this approach, I believe, simplified the implementation.
In your case, it sounds like you do care. So, just rename that variable to AM_CFLAGS and everything should work as you expect.

How to link against just built libraries in autotools project

How can I link an executable in say test subdirectory of an autotools project against a library, say libfoo, that is just built from files in src directory of same project?
Makefile.am looks like:
SUBDIRS = src . test
AUTOMAKE_OPTIONS = subdir-objects
ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS} -I m4
src/Makefile.am:
ACLCAL_AMFLAGS = ${ACLOCAL_FLAGS} -I m4
lib_LTLIBRARIES = libfoo.la
libfoo_la_SOURCES = \
foo.cpp
foo_includedir = $(includedir)/foo
foo_include_HEADERS = \
foo.hpp
test/Makefile.am:
ACLCAL_AMFLAGS = ${ACLOCAL_FLAGS} -I m4
check_PROGRAMS = footest
footest_SOURCES = \
main.cpp
footest_LDADD = ?????
That's easy: footest_LDADD = ../src/libfoo.la
This works for 'out-of-tree' builds, e.g., if you invoke configure from another directory (not ./configure).

Function not found in wrong dll

I have written a Windows application using qt, that has a number of dll dependencies. However, when i moved it to another machine, i started getting errors like "entry point ##somethingsomething not found in avformat55.dll".
The kicker is, this message is correct. The function is not in that dll at all, it is in completely different one, that is also in the folder of the executable.
Why would be function searched for in wrong place? How should that be fixed?
Edit: i have exchanged all ffmpeg dlls for ones built for x64 system; this causes program to fail to start with 0xc000007b exception; that probably has to do with system being 64-bit.
Edit. I have tried binaries on several other machines, the same mistake occurs regardles of being x64 or x86. But debug build works correctly, so it is a release build problem.
Edit: my .pro file
#-------------------------------------------------
#
# Project created by QtCreator 2013-05-17T10:55:01
#
#-------------------------------------------------
QT += core gui
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
TARGET = LPR_Demo
TEMPLATE = app
# The application version
VERSION = 1.0
# Define the preprocessor macro to get the application version in our application.
DEFINES += APP_VERSION=\\\"$$VERSION\\\"
SOURCES += main.cpp\
mainwindow.cpp \
imgProcessor.cpp \
qpicturelabel.cpp \
aboutdialog.cpp \
state.cpp \
qt_videoreader.cpp \
roidialog.cpp \
recognitionresult.cpp \
ffmpeg_reader.cpp \
label_videoplayer.cpp
HEADERS += mainwindow.h \
imgProcessor.h \
qpicturelabel.h \
aboutdialog.h \
state.h \
qt_videoreader.h \
roidialog.h \
recognitionresult.h \
global.h \
ffmpeg_reader.h \
label_videoplayer.h
FORMS += mainwindow.ui \
aboutdialog.ui \
roidialog.ui
LPRDIR = $$PWD/LPR
win32: LIBS += -L$$LPRDIR/bin/ -lliblpr
unix:LIBS += -L$$LPRDIR/bin -lLPR
INCLUDEPATH += $$LPRDIR/include
DEPENDPATH += $$LPRDIR/include
INCLUDEPATH += $$PWD/
DEPENDPATH += $$PWD/
#OTHER_FILES += \
# ffmpeg.pri
include(ffmpeg.pri)
#LIBS += -lavformat -lavcodec -lavutil -lswscale
RESOURCES += \
lpr_Res.qrc
win32 {
dlls_to_move.path += $$OUT_PWD/bin
dlls_to_move.files += $$LPRDIR/bin/liblpr.dll
QTDIR=C:/Qt/4.8.4/
CONFIG (debug, debug|release) {
dlls_to_move.files += $$QTDIR/bin/QtCored4.dll \
$$QTDIR/bin/QtGuid4.dll
}
CONFIG (release, debug|release) {
dlls_to_move.files += $$QTDIR/bin/QtCore4.dll \
$$QTDIR/bin/QtGui4.dll
}
img_format.path += $$OUT_PWD/bin/imageformats
CONFIG (debug, debug|release) {
img_format.files += $$QTDIR/plugins/imageformats/qgifd4.dll \
$$QTDIR/plugins/imageformats/qicod4.dll \
$$QTDIR/plugins/imageformats/qjpegd4.dll \
$$QTDIR/plugins/imageformats/qmngd4.dll \
$$QTDIR/plugins/imageformats/qsvgd4.dll \
$$QTDIR/plugins/imageformats/qtgad4.dll \
$$QTDIR/plugins/imageformats/qtiffd4.dll
}
CONFIG (release, debug|release) {
img_format.files += $$QTDIR/plugins/imageformats/qgif4.dll \
$$QTDIR/plugins/imageformats/qico4.dll \
$$QTDIR/plugins/imageformats/qjpeg4.dll \
$$QTDIR/plugins/imageformats/qmng4.dll \
$$QTDIR/plugins/imageformats/qsvg4.dll \
$$QTDIR/plugins/imageformats/qtga4.dll \
$$QTDIR/plugins/imageformats/qtiff4.dll
}
ffmpeg_dll.path += $$OUT_PWD/bin
ffmpeg_dll.files += $$FFMPEG_LIBRARY_PATH/avutil-*.dll \
$$FFMPEG_LIBRARY_PATH/avcodec-*.dll \
$$FFMPEG_LIBRARY_PATH/avformat-*.dll \
$$FFMPEG_LIBRARY_PATH/swscale-*.dll
main_exe.path += $$OUT_PWD/bin
CONFIG (debug, debug|release) {
main_exe.files += $$OUT_PWD/debug/LPR_Demo.exe
}
CONFIG (release, debug|release) {
main_exe.files += $$OUT_PWD/release/LPR_Demo.exe
}
INSTALLS += dlls_to_move img_format ffmpeg_dll main_exe
}
unix {
CONFIG (release, debug|release) {
QMAKE_PRE_LINK += rm LPR_Demo_cmpr LPR_Demo$$escape_expand(\n\t)
QMAKE_POST_LINK += upx -9 -oLPR_Demo_cmpr LPR_Demo$$escape_expand(\n\t)
QMAKE_POST_LINK += cp -v -u LPR_Demo_cmpr $$OUT_PWD/../artifacts/examples/qt_demo/bin/unix
}
}
and *.pri file
# Include the configuration file below in the QT .pro file, and modify the path accordingly.
# ##############################################################################
# ##############################################################################
# FFMPEG: START OF CONFIGURATION BELOW ->
# Copy these lines into your own project
# Make sure to set the path variables for:
# 1) ffmpeg_reader,
# 2) FFMPEG include path (i.e. where the directories libavcodec, libavutil, etc. lie),
# 3) the binary FFMPEG libraries (that must be compiled separately).
# Under Linux path 2 and 3 may not need to be set as these are usually in the standard include and lib path.
# Under Windows, path 2 and 3 must be set to the location where you placed the FFMPEG includes and compiled binaries
# Note that the FFMPEG dynamic librairies (i.e. the .dll files) must be in the PATH
# ##############################################################################
# ##############################################################################
# ##############################################################################
# Modify here: set FFMPEG_LIBRARY_PATH and FFMPEG_INCLUDE_PATH
# ##############################################################################
# Set FFMPEG_LIBRARY_PATH to point to the directory containing the FFmpeg import libraries (if needed - typically for Windows), i.e. the dll.a files
win32:FFMPEG_LIBRARY_PATH = $$PWD/ffmpeg/lib
unix: FFMPEG_LIBRARY_PATH = /usr/local/lib
# Set FFMPEG_INCLUDE_PATH to point to the directory containing the FFMPEG includes (if needed - typically for Windows)
win32:FFMPEG_INCLUDE_PATH = $$PWD/ffmpeg/include
unix:FFMPEG_INCLUDE_PATH = /usr/local/include
# ##############################################################################
# Do not modify: FFMPEG default settings
# ##############################################################################
# Set list of required FFmpeg libraries
#unix:LIBS += -L$$FFMPEG_LIBRARY_PATH
unix:LIBS += -lavformat -lavcodec -lavutil -lswscale
# Add the path
win32:LIBS += -L$$FFMPEG_LIBRARY_PATH
win32:LIBS += -lavformat -lavcodec -lavutil -lswscale
INCLUDEPATH += $$FFMPEG_INCLUDE_PATH
# Requied for some C99 defines
DEFINES += __STDC_CONSTANT_MACROS
# ##############################################################################
# FFMPEG: END OF CONFIGURATION
# ##############################################################################

Resources