I have an external library ace.so.
cc_library(
name='ace',
hdrs=glob(['path/to/ace/**']),
srcs=['path/to/ace.so'],
)
How do I go about linking to that library with bazel? I know a colon can be used when invoking gcc/g++ directly, but I'm not sure how to get the same behavior from bazel.
I tried adding -l:ace.so (also -Wl,-l:ace.so) to copts but it seems bazel doesn't pass that to gcc or add it to the # file used for linker args.
I tried nocopts='-lace.so' in combination with linkopts=['-l:ace.so']. No luck.
I also tried cc_import instead of cc_library, but that didn't work either.
I've read the Importing precompiled C++ libraries doc, but I didn't see anything about using libs with an arbitrary prefix - or with no prefix.
As a temporary fix, I've added a symlink libace.so pointing to ace.so and changed the srcs line to match. While this works, I'd much rather convince bazel to use the lib as is.
Looking around how information about libraries is being collected and passed around, I am afraid this (assumption that "plain" dynamic libraries are prefixed with lib and libfoo.so can be given as -lfoo is fairly hard coded at the moment. The same would not be true of it was considered a "versioned" (matches a pattern "^.+\\.so(\\.\\d+)+$") dynamic library, which would be passed as -l:foo.so.1. But unfortunately that does not really help you, because you'd still need to employ a similar workaround and create a fiction of versioning to boot. That said, as long as your solib filenames are given, the symlink sounds like a reasonably sane workaround.
Related
I've got NSBundle file named main.jsbundle packaged by react-native bundle, which tool I can use to explore it's contents? I can see that it got the minified js code inside, and also some sort of index at the beginning of file. I need to extract the js code in order to debug an issue.
NSBundle is a totally different thing – it is a native class representing an Apple format of packaging applications and frameworks, allowing to access and manipulate it from native code.
You are asking about a React Native bundle, which is quite a loose concept of a single file of minified JS code + an assets folder for images and data. You can actually de-minify the js-bundle using conventional tools such as uglify-js and try to inspect it.
You can also use sourcemaps produced by Metro, and maybe metro-symbolicate to understand how the minified code from the bundle maps to actual sources, although I can't recommend anything more specific without knowing the problem at hand. There is also no documentation for metro-symbolicate, meaning you'll have to grok its sources.
As #ivanmoskalev pointed out, this might not be necceserily NSBundle. Anyway, piping the file through strings outputs pretty much just the javascript part of the file, so that works for me.
On my way to migrate an existing build to bazel, i have a submodule mod1 that has some JUnit tests reading files from a "testdata" directory. When trying to load those files, i have to use "mod1/testdata/test.txt" instead of "testdata/test.txt", i.e. the unit tests have to be aware of their corresponding bazel module directory.
(1) Is this the correct behaviour for bazel 0.23.2#debian and 0.23.2-homebrew?
(2) Is there a way to use the .java tests without changes, and to remove the need for a "mod1" prefix in bazel data/ runfiles?
My sample project is here: https://gitlab.com/jhinrichsen/bazel-data-test. I am looking for a way to use the same path "testdata/test.txt" for both root module and submodule. In my example project, bazel test AllTests suceeds, while bazel test mod1/AllTests fails because i need to prepend "mod1/" to "testdata/test.txt".
Not looking for a resources/classpath based solution as i cannot modify the existing test sources.
The behavior that you are seeing is indeed the correct behavior, and there is no way to strip the "mod1" prefix with the native Java rules. Anything you include with data will be scoped to its own package in the way you're seeing.
The reason for this is pretty straightforward. Let's say that your test target, //mod1:AllTests, also depended on a hypothetical //mod2:tests library. And let's say that hypothetical library also had a testdata/test.txt as a data dependency. The multiple test.txt files would conflict unless they were namespaced to their packages.
If you absolutely cannot modify the test source at all, then you are pretty much stuck. Here's a previous discussion about this:
https://groups.google.com/forum/#!topic/bazel-discuss/w6TDwSZvN0k
I would recommend if you're trying to work with Bazel, you accept the concept of runfiles and modify your tests to either work with the runfiles structure, or accept a command-line argument for where to find the test data.
I made a program today, and I was wondering on how exactly to make it an executable. I've researched and I've came up with using srlua. I've asked this previously, but I usually mess up on the same instruction. I was told to 'compile srlua' While I know exactly what to do right after I compile srlua, I don't know how to compile them right now.
I've gone through a few YouTube tutorials, and I managed to find one but only in Spanish. I was able to slightly follow along until he downloaded a precompiled version of srlua, where the download link is no longer there at the same page he was at.
Would anyone be able to explain what they're trying to say?
You need to tell CMake where the Lua files it needs are.
For me, the Lua includes are in /usr/include/luaX.X, where X.X is your version number, e.g. 5.3. The Lua libraries may be in /usr/lib (with filenames like libluaX.X.so).
If the locations differ for you, you can try find / | grep "lua.h" and find / | grep "liblua".
Once you've located the folder which lua.h is in, and the appropriate library file like liblua5.3.so, you need to add these to the CMakeLists.txt file in the srlua folder.
For example, using lua5.3, you might replace this line:
include_directories(${LUA_INCLUDE_DIR})
with this one:
include_directories(/usr/include/lua5.3)
And for the libraries, you might replace this:
target_link_libraries(glue ${LUA_LIBRARIES})
target_link_libraries(srlua ${LUA_LIBRARIES})
with this:
target_link_libraries(glue /usr/lib/liblua5.3.so)
target_link_libraries(srlua /usr/lib/liblua5.3.so)
After this, run cmake ./ in the srlua folder, then run make. srlua should be built.
Note: you may also have to remove the line find_package ( Lua REQUIRED ), it was a false error for me (it only built when I removed that line).
I'm very inexperienced with Linux and the terminal, but I'm trying to learn. I've also never included an external library before. Now I need to include the Boost.Asio library in a program being developed in Ubuntu with G++.
Could someone very kindly and very carefully explain how to go about this, from the beginning?
EDIT:
Expanding on the original question: if I need to send this code to someone else for them to run it on a completely separate machine but in the same environment, how do I take that into account? If this whole process involves literally placing library files into the same folder as the code, do I just send those library files along with the .cpp to this other person?
You have mentioned you are using Ubuntu, so the simplest way to use boost is to first install libboost-all-dev package (from synaptic), which will install everything for you including those that needed to be compiled. Then you just need to use g++ in the usual way.
Please note that whether the version is what you want, if not, you may want to install it yourself. On the other hand, boost is mostly header only library, so you only need to extract the files (right click in Ubuntu...) to a folder and link to it while compiling:
g++ hello_world.cpp -I boost_1_49_0/boost
where the last one specify the path for compiler to find the boost headers (please use absolute path).
If you want to send your program to others, dont copy only some boost files, it does not work because of the dependence. Ask them to install the same environment as you while is easy (just unzip a file...).
I don't know about your specific IDE, or about Boost.Asio specifically, but in general:
Whenever you need to link to a library, there is a file named similar to lib???.a, which you need. You need to pass the -l??? flag to g++ to link to the file.
(I'm not too familiar with the details myself, so there might be other file formats and whatnot too...)
Regarding the edit:
The "right" way would be to just have them download the library themselves, and just pass -l??? to their linker. Including Boost in your source code will make it huge, and for no good reason... it's not like you include the STL in your code, after all.
You don't include the library, but instead you declare a dependency on it. Eg. consider you use autoconf and automake then you would add AX_BOOST_BASE1 to require boost and AX_BOOST_ASIO to require the ASIO libraries. In your Makefile.am file(s) you use BOOST_CPPFLAGS and BOOST_LDFLAGS macros and rely on the ./configure to set them properly. Then whoever consumes your code will have to run the well know ./configure script which will analyze the environment for the location of boost and setup appropriate values in the build environment so that the make succeeds.
Well at least this is the theory. In practice there is a reason the whole thing is better known as autohell. Alternatives exists, like CMake or boost's own bjam. But the synopsis is always the same: you declare the dependency in your build configuration and the destination location that consumes you product has to satisfy the requirement (meaning it has to download/install the required version of boost, in your case). Otherwise you enter into the business of distributing binaries and this is frowned with problems due to richness of platforms/architectures/distributions your application is expected to be deployed in.
Obviously if you use a different build system, like ANT, then you should refer to that build system documentation on how to declare the requirement for boost.
1: ax_boost.m4 is not the only boost detecting m4 library, there are other out there, but is the one documented on the GNU autoconf list of macros
I'm building a program that uses Delphi Packages (BPLs) as plugins, but I'd like to use a custom extension to show that the files have a specific purpose instead of just being BPLs. That works well enough until I end up with one package having a dependency on another. Then the compiler automatically creates the binary with the extension BPL built in.
This wouldn't be too hard to fix with a hex editor, but that's sort of an extreme solution. Is there any way I could make the compiler generate the packages with the right dependency names in the first place?
EDIT: The answers so far seem to have not understood the question.
I know exactly how to create the packages with my custom TEP extension instead of a BPL extension. But if I have package1.TEP and package2.TEP, and package2 depends on package1, and then I try to load package2, it gives an error because it can't find "package1.BPL". What I want is to find some simpler way to make package2 look for the correct filename, "package1.TEP," that doesn't involve editing the binary after it's been created. Is there any way to do that?
Use the {$E} directive.
The simplest solution would be to use a post build event to rename your destination file from *.BPL to whatever specific extension you are requiring.
EDIT:
You could write a separate patch program to search for and patch the offending binaries and run it as part of the post build process. If a patch is made to the compiler, then you can remove your step easily.