Context
I am working on a klee (http://klee.llvm.org) fork and want to clean up our repository to separate our stuff from the "canonical" klee code. Anyway, I'm having trouble understanding/extending the build system.
Problem
The directory structure in /lib/ looks like this
Basic/
Core/
Support/
Expr/
Solver/
Module/
Mine/
Mine was just added by me, so far we threw everything in Core and I am moving it to Mine. How do I tell the build system to do this properly?
My attempt
Being unable to figure this out on my own, I edited /lib/Makefile:
LEVEL=..
PARALLEL_DIRS=Basic Support Expr Solver Module Core Mine
include $(LEVEL)/Makefile.common
and copied the /lib/Core/Makefile to /lib/Mine/Makefile while changing LIBRARYNAME=kleeCore to LIBRARYNAME=kleeMine.
Caveat
I have a feeling that this is not the proper way to do it, and I should rather modify some configure script or something. Also it does not link (it compiles, though).
A colleague just told me how to get it to link, which is by modifying /tools/klee/Makefile
USEDLIBS = kleeCore.a kleeModule.a kleaverSolver.a kleaverExpr.a kleeSupport.a kleeBasic.a kleeMine.a
Related
Ok, n00b question. I have a cpp file. I can build and run it in the terminal. I can build and run it using clang++ in VSCode.
Then I add gtest to it. I can compile in the terminal with g++ -std=c++0x $FILENAME -lgtest -lgtest_main -pthread and then run, and the tests work.
I install the C++ TestMate extension in VSCode. Everything I see on the internet implies it should just work. But my test explorer is empty and I don't see any test indicators in the code window.
I've obviously missed something extremely basic. Please help!
Executables should be placed inside the out or build folder of your workspace. Or one can modify the testMate.cpp.test.executables config.
I'd say, never assume something will "just work".
You'll still have to read the manual and figure out what are the names of config properties. I won't provide exact examples, because even though I've only used this extension for a short time, its name, and therefore full properties path, has already changed, so any example might get obsolete quite fast.
The general idea is: this extension monitors some files/folders, when they change, it assumes those are executables created using either gtest or catch2. The extension tries to run them with standard (for those frameworks) flags to obtain a list of test suites and test cases. If it succeeds, it will parse the output and create a nice list in the side panel. Markers in the code are also dependent on the exactly same parsed output, so if you have one, you have the other as well.
From the above, you need 3 things to make this work:
Provide correct path (or a glob pattern) for finding all test executables (while ignoring all non-test executables) in the extension config. There are different ways to do this, depending on the complexity of your setup, they are all in the documentation though.
Do not modify the output of the test executable. For example, if you happen to print something to stdout/stderr before gtest implementation parses and processes its standard flags, extension will fail to parse the output of ./your_test_binary --gtest-list_tests.
If your test executable needs additional setup to run correctly (env vars, cwd), make sure, that you use the "advanced" configuration for the extension and you configure those properties accordingly.
To troubleshoot #2 and #3 you can turn on debug logging for the extension (again, in the VSCode's config json), this will cause an additional "Output" tab/category to be created, where you can see, which files were considered, which were run, what was the output, and what caused this exact file to be ignored.
This messed with me for a while, I did as Mate059 answered above and it didn't work.
Later on I found out that the reason it didn't work was because I was using a Linux terminal inside windows (enabled from the features section) and I previously had installed the G++ compiler using the linux terminal so the compiler was turning my code into a .out file, for some reason TestMate could not read .out files.
Once I compiled the C++ source file using the powershell terminal it created a .exe file which I then changed the path in the setting.json as Mate059 said and it showed up.
TL;DR
Mate059 gave a great answer, go into settings.json inside your .vscode folder and modify "testMate.cpp.test.executables": "filename.exe".
For me it also worked using the wildcard * instead of filename.exe but I do not suggest to do that as in that might mess up something with the .exe from the main cpp file and what not.
I'm struggling to implement AppsFlyer on Android using Java.
I have looked into a couple of posts already such as this, this.
Here is the entire error message: [org.gradle.api.Project] AGPBI: {"kind":"error","text":"Program type already present: com.appsflyer.AFExecutor","sources":[{}],"tool":"D8"}
The version
AppsFlyer SDK: 5.+
Android Studio: 3.5.2
Situation
I have done till 4.1 of this guide so far so good.
On AndroidManifest.xml, the main class name of AF has implemented with android.name attribute.
On AndroidManifest.xml, receiver tag commented out (because in this phase I don't believe I do not need a precise data tracking feature.)
What I have tried.
./gradlew app:dependencies | less To find out AFExecutor in other dependencies
To exclude the program
implementation ('com.appsflyer:af-android-sdk:5.+'){
exclude module: 'com.appsflyer'
}
implementation ('com.appsflyer:af-android-sdk:5.+'){
exclude module: 'AFExecutor'
}
If you have any insights, I'd love to hear that.
Try ./gradlew clean, clean project and invalidate caches and restart. If does not help than delete all build and .idea folders, .iml files.
After exploring a bunch of dependencies, I found the solution. The reason was there was a conflict between com.appsflyer:af-android-sdk:5.+ and AF-Android-SDK.jar which had installed manually. After removing the JAR file and built again, I could make it at last! Thank you so much for sharing your experiences, however, the solution was simple!
The title of this question does not begin to capture my years of exasperation with the RPM system. There is a vast gulf between a development system (./configure; make; make install;) and a rpm system (tar files, patch files, spec files, arcane build scripts, environments and tools) which I cannot bridge.
All I want to do is to change a few lines of code in a bigger program.
The problems which I run into:
Getting the source code of the system as-installed (e.g. SRPM from EPEL, original tarball, something else). What source should I use?
Getting that source code into a ready-to-edit form - something that I can edit with my favourite editor. How can I know that I'm editing the code as-deployed, bugs and all? (rpm -ivh x.src.rpm gives me tar files and squabs of patch files littered about in the SOURCES directory ... how can I get it right?)
Editing the code to implement some amazing hack (this part I can actually do).
Compiling the amazing code as edited - just compiling it in-place. Usually I can get this right, but it would be nice to have a hand sometimes, e.g. with ./configure set to use something other than the default /usr/local and /lost+found/opt/etc/opt or whatever crazy default autoconf decides to use.
Transforming my edits into a patch against the previous source and building new RPMs to test on some remote system (this is the great promise of RPM - pristine sources and hacky patches). If I do a diff of the original and the edited directories, the resulting patch contains all sorts of rubbish that I don't want to delete because I'm still developing (e.g. object code). (Actually, I don't have an 'original' at this point to do a diff against ... because I was only looking at the code casually when I realised I could "improve" it ...) Should I use some revision control system to track the changes I am making?
This should be simple stuff, but somehow all I can do is edit the code. After I have edited the code, it can never get over the hump, even though it is an already-solved problem. I have a GREAT fix for an open source project, but every single time that I finish developing my amazing hack, having delved into the code and made it compile (and possibly work), I am completely stumped. Nothing at all can turn my modified and now amazing source tree into a RPM. I end up deploying source code (into /usr/local), because that at least works.
How do people who do (say) security fixes actually go about the extract-edit-compile-test loop?
The SRPM is (relatively) self-contained: there are often some assumptions about build requirements not reflected in the spec file.
I would start by taking the SRPM, and rebuilding it to address the issue of build-requirements (adding whatever is needed to get it to build).
Then, extract the spec-file and sources from the SRPM, putting the patches and tar-file(s) into ~/rpmbuild/SOURCES, and building from the spec-file
Next, modify the spec-file to add my own patch file (or scripting changes),
Finally there's a new SRPM with my changes.
For extracting, I use an unrpm script (essentially a wrapper around cpio) which can be found on the network.
Making your own patch file is discussed here:
HowTo Create A Patch File For A RPM
RPM - Creating Patches
Patches for .spec file
I am writing an LLVM pass, just following http://llvm.org/docs/WritingAnLLVMPass.html#basic-code-required.
I have finished the Makefile, the source code, however, when I came to do the make:
Now that it’s all together, compile the file with a simple “gmake” command in the local directory and you should get a new file “Debug+Asserts/lib/Hello.so” under the top level directory of the LLVM source tree (not in the local directory).
It reported
../../../Makefile.common:61: ../../../Makefile.config: No such file or directory
../../../Makefile.common:69: /Makefile.rules: No such file or directory
make: *** No rule to make target '/Makefile.rules'. Stop.
I didn't change the any configuration files in the root directory. There is no Makefile.config in my root directory, but there is a file called Makefile.config.in. Makefile.common appears in the root directory.
I hate to be the one to tell you, but I think you'll need to get your basics straight before diving into compiler development:
http://llvm.org/docs/WritingAnLLVMPass.html has a lot of documentation that you should definitely read, including information on the Manager:
The PassManager class takes a list of passes, ensures their prerequisites are set up correctly, and then schedules passes to run efficiently. All of the LLVM tools that run passes use the PassManager for execution of these passes.
A makefile is a mechanism of defining how a piece of software is built by compiler, linker, installation scripts etc. How that will look like depends completely on how you plan to implement your software. In your case, you should definitely orientate yourself on existing passes. In fact, http://llvm.org/docs/WritingAnLLVMPass.html#setting-up-the-build-environment has a rather detailed explanation on how to set up the makefile, including a template, which is really simple
# Makefile for hello pass
# Path to top level of LLVM hierarchy
LEVEL = ../../..
# Name of the library to build
LIBRARYNAME = Hello
# Make the shared library become a loadable module so the tools can
# dlopen/dlsym on the resulting library.
LOADABLE_MODULE = 1
# Include the makefile implementation stuff
include $(LEVEL)/Makefile.common
If you don't understand that, you'll have to read a bit of existing Makefiles or make documentation.
All in all, I think writing LLVM passes might not be the thing I'd get started with if not being used to these kind of standard tools, but I recommend just diving into the LLVM source code tree to get a feeling. Practice makes a master!
I have a working C-extension for Racket. In the Racket CLI and the interactions window of DrRacket it works like a charm. However, I can't get it to work in the definitions window of DrRacket, which would be really useful as that is the interface for my students to develop their programs.
The problem seems to be that definitions in the extension are not 'seen' (or registered or something). The module is loaded (or at least found) but DrRacket complains that it doesn't have execute permission for it, which I don't understand.
In the C code I declared the extension to be a module and I tried both inclusion methods:
(load-extension "racket_extension.so")
and
(require "racket_extension.rkt") ; which requires you put it in a folder relative to the current working folder as follows:
"compiled/native/x86_64-linux/3m/racket_extension_rkt.so"
Neither method works. The first case gives no error, but the definitions of the external are not registered ("undefined").
In the second case DrRacket gives an error:
forbidden (execute) access to ....compiled/native/x86_64-linux/3m/racket_extension_rkt.so
but why?
Does anyone have ideas how I can get this to work? What am I missing?
Thanks!
Marc
How are you compiling and linking your extension? Are you using the raco ctool or gcc? Are you executing DrRacket within the same directory as your compiled directory? The way I usually test my extensions is to execute: drracket my_ext_test.rkt in the same directory as my compiled directory. That has been an issue for me in the past. Also, if it says the action is forbidden, did you try changing the permissions of your .so? Maybe it's something as simple as that. I'd start with the simple example Writing Racket Extensions and make sure that you can get the hello world program to work in the definitions window. I personally have never had the problem you have mentioned, but I am also running on Linux.