I am adding a custom recipe to my image. It is bases on DBCPPP. This project is built using cmake. My issue only comes to light when I include a new layer meta-swupdate. It seems meta-swupdate alters the kernel in a way that conflicts with dbcppp. My full error is:
Error: Transaction test error:
file /usr/lib/libxml2.so.2.9.10 conflicts between attempted installs of dbcppp-1.0+gitr0+fa8ce17468-r0.cortexa7t2hf_neon and libxml2-2.9.10-r0.cortexa7t2hf_neon
To build and include dbcppp I added the recipe:
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI = "gitsm://github.com/xR3b0rn/dbcppp.git;protocol=https;branch=master"
PV = "1.0+gitr${SRCPV}"
SRCREV = "${AUTOREV}"
DEPENDS += " boost"
S = "${WORKDIR}/git"
inherit pkgconfig cmake
FILES_${PN} += "/usr/lib/xml2Conf.sh /usr/lib/lib*.so.*"
SOLIBS = ".so"
FILES_SOLIBSDEV = ""
INSANE_SKIP_${PN} += "dev-so"
I have read a few other questions and attempted two solutions by adding a do_install_append step.
Change folder permission level install -d 0755 ${D}/usr/lib
Remove the folder rm -rf ${D}/usr/lib
Neither solution worked. I need both libraries in my application and I unsure how to proceed.
Edit: After some further reading I found a suggestion to delete the tmp, cache, and sstate-chace folders. I did this but I receive the same error.
Edit: My local.conf has PACKAGE_CLASSES ?= 'package_rpm' defined. if I remove this I still get a do_rootfs error, but the error message is not helpful.
Edit: In my recipe for dbcppp I have attempted to remove the file in question. This gives me the same error. Makes no difference.
do_install_append() {
rm -rf /usr/lib/libxml2.so.2.9.10
}
I created a basic kernel module that I plan to use eventually for a timing analysis. I am running a v4.14.149 mainline kernel and am building it with Yocto Zeus running on an i.MX6 target. I can't seem to get it to launch automatically.
Everything compiles fine, and I see my testmodule.ko show up in /lib/modules/4.14.149/extras/ on target. I can load it and unload it just fine with insmod and rmmod so I am pretty sure the module is OK. I also see a testmodule.conf file that contains the module name (testmodule) in /etc/modules-load.d/ but when I boot and do a lsmod I don't see it loaded. I also don't see any output in journalctl that would indicate that it loaded.
I have looked at and tried Yocto: Adding kernel module recipe to image, but it doesn't load on boot and Yocto load kernel module and have added KERNEL_MODULE_AUTOLOAD += "testmodule" in my machine configuration and I also tried it in the module recipe to no avail. I am including the module in my image recipe via IMAGE_INSTALL_append as kernel-module-test.
Here is the recipe for my module:
SUMMARY = "Test kernel module"
LICENSE = "CLOSED"
inherit module
SRC_URI = "file://Makefile \
file://testmodule.c"
S = "${WORKDIR}"
KERNEL_MODULE_AUTOLOAD += "testmodule"
RPROVIDES_${PN} += "kernel-module-test"
The module code at the moment just prints a message (it was a sample from a Yocto book I had) and that is it:
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/module.h>
/*
** Module Init function
*/
static int hello_world_init(void)
{
printk("Markem Kernel Module Inserted Successfully...\n");
return 0;
}
/*
** Module Exit function
*/
static void hello_world_exit(void)
{
printk("Markem Kernel Module Removed Successfully...\n");
}
module_init(hello_world_init);
module_exit(hello_world_exit);
MODULE_LICENSE("Proprietary");
/*
MODULE_VERSION("0.1");
MODULE_DESCRIPTION("A test module.");
MODULE_AUTHOR("Markem-Imaje Corporation");
*/
And lastly the Makefile, which is also based on the Yocto Book sample
obj-m := testmodule.o
SRC := $(shell pwd)
all:
$(MAKE) -C $(KERNEL_SRC) M=$(SRC)
modules_install:
$(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install
clean:
rm -f *.o *~ core .depend .*.cmd *.ko *.mod.c
rm -f Module.markers Module.symvers modules.order
rm -rf .tmp_versions Modules.symvers
If you need the recipe for my kernel or my machine conf or anything, I can get those. Everything I have read indicates that having the file in /etc/modules-load.d/ indicates it should load automatically. Is there possibly a kernel configuration I am missing or something?
I am creating a module from an autotools+libtool project:
The Makefile.am looks as follows
#the module:
lib_LTLIBRARIES = mmmm.la
mmmm_la_SOURCES = mmmm.c
mmmm_la_LDFLAGS = $(AM_LDFLAGS) -module -shared
Now, I want to write a C test for my module. The test should start loading the shared object mmmm.xx (where .xx is .so or .la)
What path should I give to dlopen() or lt_dlopen() in my C test?: The relative location of my module (compared to the test program) is different depending on whether I do make check, an out of tree make check, or a make installcheck...
I tried with lt_dlopen() hoping that the -dlopen option passed on the test Makefile.am would help autotools to locate the lib when lt_dlopen() is called, but it does not seem to help: lt_dlopen() can open the .la file, indeed, but one still have to tell where that file is located (possibly ommiting the .libs directory)
My test makefile looks like this when testing with the ltdl lib:
#the module test (tests are also installed, hence the "test" prefix)
test_PROGRAMS = tttt
tttt_SOURCES = tttt.c
tttt_LDADD = "-dlopen" mmmm.la
tttt_DEPENDENCIES = mmmm.la
Any good hint?
One way you can deal with that is to set up the LD_LIBRARY_PATH env variable to where your library will be installed.
However, since you need it for the tests I will say export a variable from the configure.ac to the config.h. Thus, any file including the config.h would have a #define your_variable which can be used to set up the path for dlopen.
I'm starting out with Autotools, and I'm trying to package a library (a generic stack implementation for learning purposes) along with some usage examples.
The library source lives in src and the example in examples.
I have the following Makefile.am:
lib_LTLIBRARIES = libstack.la
libstack_la_SOURCES = src/stack.c
check_PROGRAMS = example/stack
example_stack_SOURCES = example/stack.c
example_stack_LDADD = libstack.la
As long as my understanding goes, I need to specify a header for libstack.la, and include that from my example, but I get the following error when running autoreconf after adding libstack_la_HEADERS = src/stack.h to Makefile.am:
$ autoreconf -iv
... (omiting irrelevant parts)
Makefile.am:3: error: 'libstack_la_HEADERS' is used but 'libstack_ladir' is undefined
autoreconf: automake failed with exit status: 1
I couldn't find any information related to the dir prefix.
What am I missing here?
To handle header of library you should write something like this:
libstackincludedir = $(includedir)/my_mega_stack
libstackinclude_HEADERS = stack.h
Messing about with various settings for unit-testing plug-ins left me with a discombobulated project file. I seem to have fixed it, but there is one side effect: everytime I run the plug-in, the console fills with warnings for each and every class file, like so:
warning: Could not find object file "/Users/elisevanlooij/Documents/Project Plug-ins/MyPlugin 8/build/MyPlugin.build/Debug/MyPlugin.build/Objects-normal/i386/MyPlugin.o" - no debug information available for "/Users/elisevanlooij/Documents/Project Plug-ins/MyPlugin 8/MyPlugin.m".
Now I can quite understand why the error occurs since the path /Users/elisevanlooij/Documents/Project Plug-ins/MyPlugin 8 no longer exists: "MyPlugin 8" was temporary folder (a checkout for svn version 8 of MyPlugin) that has long since gone to the trashcan, which has been emptied too. The current version of MyPlugin should not even know about it, but somehow, for some reason Xcode and/or gdb won't let go. I've even thrown away the relevant caches in the Precompiled Headers Cach path, but no joy. Googling has revealed other people with the problem, but no solution. Who can help?
These are the build settings (Debug) that have values. They are, by the way, as far as I can see, the same as a plug-in that does not have this problem.
ARCHS = $(ARCHS_STANDARD_32_BIT)
SDKROOT = macosx10.5
ONLY_ACTIVE_ARCH = YES
VALID_ARCHS = i386 ppc ppc64 ppc7400 ppc970 x86_64
SYMROOT = build
OBJROOT = $(SYMROOT)
CONFIGURATION_BUILD_DIR = $(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)
CONFIGURATION_TEMP_DIR = $(PROJECT_TEMP_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)
SHARED_PRECOMPS_DIR = $(CACHE_ROOT)/SharedPrecompiledHeaders
BUILD_VARIANTS = normal
DEBUG_INFORMATION_FORMAT = dwarf
ENABLE_OPENMP_SUPPORT = NO
GENERATE_PROFILING_CODE = NO
PRECOMPS_INCLUDE_HEADERS_FROM_BUILT_PRODUCTS_DIR = YES
SCAN_ALL_SOURCE_FILES_FOR_INCLUDES = NO
ALTERNATE_GROUP = $(INSTALL_GROUP)
ALTERNATE_OWNER = $(INSTALL_OWNER)
ALTERNATE_MODE = $(INSTALL_MODE_FLAG)
DEPLOYMENT_LOCATION = NO
DEPLOYMENT_POSTPROCESSING = NO
INSTALL_GROUP = $(GROUP)
INSTALL_OWNER = $(USER)
INSTALL_MODE_FLAG = u+w,go-w,a+rX
DSTROOT = /tmp/$(PROJECT_NAME).dst
INSTALL_PATH = $(HOME)/Library/Application Support/Twee Bomen plug-ins
SKIP_INSTALL = NO
COPY_PHASE_STRIP = NO
STRIP_STYLE = non-global
SEPARATE_STRIP = NO
STANDARD_C_PLUS_PLUS_LIBRARY_TYPE = dynamic
DEAD_CODE_STRIPPING = NO
LINKER_DISPLAYS_MANGLED_NAMES = NO
PRESERVE_DEAD_CODE_INITS_AND_TERMS = NO
LINK_WITH_STANDARD_LIBRARIES = YES
MACH_O_TYPE = mh_bundle
LD_OPENMP_FLAGS = -fopenmp
LD_MAP_FILE_PATH = $(TARGET_TEMP_DIR)/$(PRODUCT_NAME)-LinkMap-$(CURRENT_VARIANT)-$(CURRENT_ARCH).txt
GENERATE_MASTER_OBJECT_FILE = NO
PREBINDING = NO
KEEP_PRIVATE_EXTERNS = NO
SEPARATE_SYMBOL_EDIT = NO
LD_GENERATE_MAP_FILE = NO
APPLY_RULES_IN_COPY_FILES = NO
INFOPLIST_EXPAND_BUILD_SETTINGS = YES
GENERATE_PKGINFO_FILE = NO
FRAMEWORK_VERSION = A
INFOPLIST_FILE = Info.plist
INFOPLIST_OUTPUT_FORMAT = same-as-input
INFOPLIST_PREPROCESS = NO
COPYING_PRESERVES_HFS_DATA = NO
PRIVATE_HEADERS_FOLDER_PATH = $(CONTENTS_FOLDER_PATH)/PrivateHeaders
PRODUCT_NAME = MyPlugin
PLIST_FILE_OUTPUT_FORMAT = same-as-input
PUBLIC_HEADERS_FOLDER_PATH = $(CONTENTS_FOLDER_PATH)/Headers
STRINGS_FILE_OUTPUT_ENCODING = UTF-16
WRAPPER_EXTENSION = tbplugin
ALWAYS_SEARCH_USER_PATHS = NO
EXCLUDED_RECURSIVE_SEARCH_PATH_SUBDIRECTORIES = *.nib *.lproj *.framework *.gch (*) CVS .svn *.xcodeproj *.xcode *.pbproj *.pbxproj
VERSION_INFO_FILE = $(PRODUCT_NAME)_vers.c
VERSION_INFO_BUILDER = $(USER)
GCC_FAST_OBJC_DISPATCH = YES
GCC_AUTO_VECTORIZATION = NO
GCC_OBJC_CALL_CXX_CDTORS = NO
GCC_ENABLE_SSE3_EXTENSIONS = NO
GCC_ENABLE_SUPPLEMENTAL_SSE3_INSTRUCTIONS = NO
GCC_STRICT_ALIASING = NO
GCC_FEEDBACK_DIRECTED_OPTIMIZATION = Off
GCC_ENABLE_FIX_AND_CONTINUE = YES
GCC_GENERATE_DEBUGGING_SYMBOLS = YES
GCC_DYNAMIC_NO_PIC = NO
GCC_GENERATE_TEST_COVERAGE_FILES = NO
GCC_INLINES_ARE_PRIVATE_EXTERN = YES
GCC_MODEL_TUNING = G5
GCC_INSTRUMENT_PROGRAM_FLOW_ARCS = NO
GCC_ENABLE_KERNEL_DEVELOPMENT = NO
GCC_DEBUGGING_SYMBOLS = default
GCC_REUSE_STRINGS = YES
GCC_NO_COMMON_BLOCKS = NO
GCC_ENABLE_OBJC_GC = supported
GCC_OPTIMIZATION_LEVEL = 0
GCC_FAST_MATH = NO
GCC_ENABLE_SYMBOL_SEPARATION = YES
GCC_THREADSAFE_STATICS = YES
GCC_SYMBOLS_PRIVATE_EXTERN = NO
GCC_UNROLL_LOOPS = NO
GCC_MODEL_PPC64 = NO
GCC_CHAR_IS_UNSIGNED_CHAR = NO
GCC_ENABLE_ASM_KEYWORD = YES
GCC_PFE_FILE_C_DIALECTS = c objective-c c++ objective-c++
GCC_C_LANGUAGE_STANDARD = c99
GCC_CHECK_RETURN_VALUE_OF_OPERATOR_NEW = NO
GCC_CW_ASM_SYNTAX = YES
GCC_INPUT_FILETYPE = automatic
GCC_ALTIVEC_EXTENSIONS = NO
GCC_ENABLE_CPP_EXCEPTIONS = YES
GCC_ENABLE_CPP_RTTI = YES
GCC_LINK_WITH_DYNAMIC_LIBRARIES = YES
GCC_ENABLE_OBJC_EXCEPTIONS = YES
GCC_ENABLE_TRIGRAPHS = NO
GCC_ENABLE_FLOATING_POINT_LIBRARY_CALLS = NO
GCC_USE_INDIRECT_FUNCTION_CALLS = NO
GCC_USE_REGISTER_FUNCTION_CALLS = NO
GCC_INCREASE_PRECOMPILED_HEADER_SHARING = NO
OTHER_CPLUSPLUSFLAGS = $(OTHER_CFLAGS)
GCC_PRECOMPILE_PREFIX_HEADER = YES
GCC_PREFIX_HEADER = MyPlugin_Prefix.pch
GCC_ENABLE_BUILTIN_FUNCTIONS = YES
GCC_ENABLE_PASCAL_STRINGS = YES
GCC_FORCE_CPU_SUBTYPE_ALL = NO
GCC_SHORT_ENUMS = NO
GCC_USE_GCC3_PFE_SUPPORT = $(USE_GCC3_PFE_SUPPORT)
GCC_ONE_BYTE_BOOL = NO
GCC_USE_STANDARD_INCLUDE_SEARCHING = YES
GCC_PREPROCESSOR_DEFINITIONS =
GCC_PREPROCESSOR_DEFINITIONS_NOT_USED_IN_PRECOMPS =
I had this problem as well while debugging a shared library. Turns out a wrong, outdated library was being loaded. Try typing 'info target' at the GDB prompt, and look at the paths to check that the object and library files are correct and are the ones that you have just built.
gdb is trying to load debugging information which is stored in the object files and not in the plugin. If you need to debug your plugin, the simplest solution is to keep the object files around. If you don't, then you can remove the [partial, incomplete] debug info from the plugin to get rid of the warnings with 'strip -S yourplugin'. I just ran into a related problem myself and answered more completely on this other question.
I had the same problem.
When starting gdb I could see a lot of
"warning: Could not find object file...".
Then when doing "backtrace", I could only see the function names but not the line number.
The problem was that my binary was universal. In my make file, I was doing:
gcc -ggdb -arch ppc64 -arch x86_64 ...
The solution to get rid of the warnings and to see the line number was to use only a single architecture.
In your post I can see that you have a lot of architectures.
VALID_ARCHS = i386 ppc ppc64 ppc7400 ppc970 x86_64
It's been long time now, but if you can, you can try with only one to see if you have the same problem.
Unfortunately this solution is not perfect, because in a perfect world I still want to continue to use a fat (universal) binary and be able to use gdb!
GNU gdb 6.3.50-20050815 (Apple version gdb-1472)
gcc version 4.2.1 (Apple Inc. build 5664)
Not sure if this is your case, but when I had this problem it was because I forgot to add the implementation file to the test target.
You are still running the binary that was built from the old (removed) location, and you must rebuild that binary.
The path to .o files is "baked" into MyPlugin.m at static link time.
There is no magic by which GDB would remember that old location if you were debugging MyPlugin.m built using object files in the new location.
I just had the same problem after changing the build location of a Photoshop plug-in that I was working on. I moved the old build folder to the trash, but it turned out that Photoshop keeps an alias to the folder, which adjusts to the new location in the trash, so it would still load that old plugin from the trash, instead of the new one.
The 'info target' command pointed me to the problem.
I just had the same problem but with a framework.
I fixed it by building the framework with Build Configuration set to Release in the scheme.
How do I debug C++0x programs in MacPorts gcc 4.5?
adding -pedantic flag fixes this. Check the path that you are compiling from and if you don't see a .dSYM file, that is your culprit. That obv needs to be there per/executable, and for whatever reason -pedantic fixes this. I had the exact same problem until I stumbled on the above link.
EDIT: Problem came back and my solution wasn't working, but then I remembered something I also did that I didn't mention: it seems switching the order of the files at the end of the command line seemed to regenerate the dSYM file. So in my case, I had a header file and to .c files. I just switched the order of 2 of them and problem solved. (don't know why this works, but I guess anything to trick the computer into viewing the compile as a new scenario)
You need to change GENERATE_DEBUGGING to NO. Then clean the project and build again it will be fixed
I don't have a good answer to this question: I've considered removing the question, but it is a real problem and there are only one or two other mentions of it on the internet, with no solutions either. So, if you're struggling with this: I feel your pain but unfortunately the only way I've found to deal with it is to start a new project and import all classes and other resources.
But please feel free to contribute and if you come up with something better than starting over, I'll be happy to accept your answer.