I have a dapptools project, and when I run dapp test I get the following before my tests happen:
dapp-build: building with linked libraries
dapp: Predeploying test library lib/openzeppelin-contracts/contracts/utils/Address.sol:Address at 0x1F39490BdD8e57Ed3CA877783E563cC0B329431b
dapp: Predeploying test library lib/openzeppelin-contracts/contracts/utils/Strings.sol:Strings at 0x7496c5C5c86FB8cE60221e5BeFf3b7806CFd09a7
However, I have another project where this doesn't happen. This seems to take a lot of time.
What's going on?
Create a .dapprc if you don't have one already, and add:
export DAPP_LINK_TEST_LIBRARIES=0
This will skip compiling all the files in the lib folder, which we don't need to do.
Related
I have a project where the library sources were set up the following way:
MyProject
|_MyProject.pro
|_MainStuff
|_MainStuff.pro
|_ManyFiles
|_Tests
|_Tests.pro
|_LotsOfTests
|_MyLibs
| FunLibs.pro
|_FunLib1.h
|_FunLib1.cpp
|_FunLib2.h
|_FunLib2.cpp
This is not ideal, because as the number of FunLibs increases, all of it would be included into a single shared object. With this setup, everything builds and runs just fine. Just to be clear: MyProject.pro is a subdirs template, the MainStuff.pro is an app template, and the FunLibs is a lib template.
The problem stats, when I rearrange the files the following way:
MyProject
|_MainStuff
|_ ManyFiles
|_Tests
|_LotsOfTests
|_MyLibs
|_MyLibs.pro
|_FunLib1
|_FunLib1.pro
|_FunLib1.h
|_FunLib1.cpp
|_FunLib2
|_FunLib2.pro
|_FunLib2.h
|_FunLib2.cpp
Here the MyLibs.pro becomes a subdir tempalte, while the FunLibx.pro files will be lib templates. All configurations have been updated accordingly and the application builds. The problem is that when I now try to launch the application, the following message pops up:
libFunLib1.so.1: cannot open shared object file: No such file or
directory
I don't really understand why doesn't it work now, when it worked with the previous directory structure. This post for example (as many others) recommends to set the LD_LIBRARY_PATH by exporting the dir, but to be honest, I didn't have to do this with the previous setup.
I also have everything set up pretty much as described in the official docs under the "Creating a shared library" part.
Does anybody have an idea what might be the problem? Is there a way to solve this by not exporting the path?
Thanks in advance.
OK, I think I found out what can fix the aforementioned problem. Qt Creator also uses LD_LIBRARY_PATH environment variable for executing compiled programs, but it is somewhat hidden. As it turns out, it is able to use separate sets of env variables for compiling and running applications, and if the env vars for running are not properly defined, the user will get the error message mentioned in the original post, even if the program compiled properly.
To make sure all lib paths are included for running as well, one needs to check out the included paths here:
Projects (mode) --> Run Settings (under Build & Run) --> Run
Environment (expand the Details) --> LD_LIBRARY_PATH (somewhere in the
list)
If that var doesn't include the proper paths, it can be edited after which it is going to get highlighted. After setting this, everything seems to work.
I've got a problem with compiling my basic code with MOOS-ivp.
I made main.cpp, simpleApp.cpp and simpleApp.h from documentation, where should I put it to build it with moos? In docs there is note about launching MOOSDB and uMS - ok, but there is not any option to find path to my .cpp file. Is there any default path? Maybe should I compile it firstly with gcc?
I'll assume you know some basic information about MOOS or are taking the MIT 2.680 course and know some of the terminology talked about in the introduction lab.
The recommended way to build external MOOS is to have moos-ivp and moos-ivp-extend in a directory next to each other. You should run GenMOOSApp_AppCasting in the moos-ivp-extend/src directory and add your new project to the CMakeLists.txt file in the same directory. Then, use the included ./build.sh script to build your executables, and add the directory it makes to your $PATH.
Finally, you should be able to run your mission with your new MOOS app.
I'm a long time VB programmer, and pretty good with c#, but I'm dumb as a brick when it comes to c++. But nonetheless, I need to build the source code for GraphicsMagick.NET, specifically for .net 2.0 if I can, to try to see if I can convert it to a fully managed dll, so that I can import it into Unity3D (who cares why I need to build it?).
Anyway, without posting the entire project here, I realize it might be hard for anyone here to know exactly what is causing my error. But perhaps someone can give an educated guess? Edit: you can download a zip of the full source from https://graphicsmagick.codeplex.com/SourceControl/latest if you want to see all the code I'm working with that is giving me this error.
This project, I assume, is supposed to compile without errors right out of the box. But it doesn't. It has this line of code in the include.h file:
# if defined(HasBZLIB)
# pragma comment(lib, "CORE_RL_bzlib_.lib")
# endif
and as a result of this evil line, I'm getting this evil error:
LNK1104 cannot open file 'CORE_RL_coders_.lib'
GraphicsMagick.NET.net20
C:\Users\A\Downloads\graphicsmagick-d\GraphicsMagick.NET.net20\LINK 1
Being the good VB programmer, I searched my project folder extensively, and that _.lib file doesn't exist. But in the process of searching online, I learned that c++ sometimes generates .lib files when you build a project. So perhaps this file was supposed to be built first, before it was linked, but for whatever reason it didn't get built first? You can see how clueless I am with c++.
Of course I commented out the line. But then it simply generates an error on the next line, which is another .lib file missing. I assume it will generate an error on every _.lib file in the entire include.h file, and there are a fair number of them.
Why is this project, which is supposed to build, missing so many .lib files? Can anyone give an educated guess why? am I probably missing some dependency that the author of this project forgot to mention in the installation instructions? Or would it be more likely that these .lib files are supposed to be created by me somehow, and I'm just not building it right?
In the downloaded release under GraphicsMagick there are two script files called CopyLibsFromDropbox.cmd and CopyLibsToDropbox.cmd, the first of which contains
echo You can download the library files here: https://www.dropbox.com/sh/a8krszzmo76fqkt/AAAc9Jho29Jk3iLrKhsBmw-Ma?dl=0
goto done
In that dropbox, you will find all the lib files you need. Download the whole thing as a .zip and extract the thing inside the the \GraphicsMagick directory. Should look like that now:
Once the libs are inside that folder you can actually compile the code. The scripts are for copying them from your local dropbox directory to this directory, if you choose to "save this inside my dropbox" at the dropbox download page above. In the end, you should see something like
3> GraphicsMagick.NET.Web -> C:\Users\Maxi\Downloads\graphicsmagick-d1b5b1b28f26cdedf3ceeb555b94a87609286740\GraphicsMagick.NET.Web\bin\ReleaseQ16\x86\GraphicsMagick.NET.Web-x86.dll
3> Codeanalysis is beeing executed...
3> Codeanalysis finished -- 0 Errors, 0 Warning(s)
========== Build: 2 successfull, 0 failed, 0 recent, 1 skipped ==========
(who cares why I need to build it?)
I do. You can already include managed dlls to Unity, and GraphicsMagick.NET already gives you a .NET dll which you should be able to use within Unity, or did you have any particular problems with that? Need some image processing functionality from that library?
Our project contains a lot of c++ sources, up until now we were sing make to build everything, however this takes ages. So I stumbled upon waf, which works quite well and speeds up the build a lot. However everytime I do a full build I end up with a couple of build errors that make no sense. If I do an incremental build now, most of the time some of the sources that could not be build the first time around are build now, some others still fail. On another incremental build I will finally get a successful build.
I have tried building the separate libraries in separate steps, just in case any dependent libraries are attempted to build in parallel, but the errors still appear.
EDIT: The errors I keep getting do not seem to have anything to do with my code, e.g.
Build failed
-> task failed (exit status -1):
{task 10777520: c constr_SET.c -> constr_SET.c.1.o}
After another "waf build" I do not get this error anymore.
EDIT2: The build step for my libraries looks like this:
def build(bld):
bld.shlib(source="foo.cpp bar.cpp foobar.cpp constr_SET.c",
target="foobar",
includes= "../ifinc",
name="foobar",
use="MAIN RW HEADERS",
install_path = "lib/")
MAIN, RW, HEADERS are just some flags and external libraries we use.
Has anyone seen similar behaviour on their system? Or even a solution?
I'm suspecting multiple targets are building the same required object in parallel. Try
export JOBS=1
or
waf --jobs 1
I am developing a DLL in C++ and want to perform unit testing of that DLL using the Boost Test Libraries. I read the Boost test manual thoroughly but since I am new, I have the following question:
Should I add test classes in the same VC project in which I am developing my DLL?. Ideally I want to do this but I am confused that a DLL has no main() and, on the other hand, the Boost test needs its own main() to execute. So where does the Boost test output go in this scenario? (In fact, I practically implemented this and don't see any output :( and almost spent two days I figuring out the problem, but didn't succeed)
Regards,
Jame.
You have 3 ways to do this:
You can definitely do what another reply suggest and build your lib as static. I wouldn't recommend this way though.
You can have one or more separate unit test projects in your solution. These projects will link with your library and with either static or shared version of Boost Test library. Each project will have a main either supplied by the Boost.Test library or implemented by you manually.
Finally you have another option and you can put your test cases directly into your library. You'll need to link with shared version of Boost Test. Once your library is built you can use it regularly as you do now plus you'll have an ability to execute test cases built into it. To execute the test case you'll need a test runner. Boost Test supplies one called "console test runner". You'll need to build it once and you can use for all your projects. Using this test runner you can execute your unit test like this:
test_runner.exe --test "your_lib".dll
You should understand all the pluses and minuses of this approach. Your unit test code will be part of your production library. It'll make it slightly bigger, but on the other hand you'll be able to run the test in production if necessary.
You could build your DLL as a static library file first. You can then use it to compile your final DLL directly and create an executable that contains your boost tests. Here's an example using boost.build:
lib lib_base
: # sources
$(MAIN_SOURCES).cpp # Sources for the library.
: # requirements
<link>static
: : ;
lib dll_final
: # sources
lib_base
$(DLL_SOURCES).cpp # Sources for DllMain .
: # requirements
<link>shared
: : ;
unit-test test_exe
: # sources
lib_base
$(TEST_SOURCES).cpp # Sources for the unit tests.
: # properties
<library>/site-config//boost/test
;
You do have to be carefull to not have any important logic in your DllMain but that's usually a bad idea.