I'm trying to compile some Vala on ArchLinux, and when I try to include the package gtk+-3.0, it seems GDK and GTK+ 2.0 are being included as well; valac --pkg gtk+-3.0 test.vala gives the following errors:
gdk-2.0.vapi:8.3-8.28: error: `Gdk.Selection' already contains a definition for `convert'
public static void convert (Gdk.Window requestor, Gdk.Atom selection, Gdk.Atom target, uint32 time_);
^^^^^^^^^^^^^^^^^^^^^^^^^^
gdk-3.0.vapi:8.3-8.28: note: previous definition of `convert' was here
public static void convert (Gdk.Window requestor, Gdk.Atom selection, Gdk.Atom target, uint32 time_);
^^^^^^^^^^^^^^^^^^^^^^^^^^
gdk-2.0.vapi:10.3-10.44: error: `Gdk.Selection' already contains a definition for `owner_get'
public static unowned Gdk.Window owner_get (Gdk.Atom selection);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
gdk-3.0.vapi:10.3-10.44: note: previous definition of `owner_get' was here
public static unowned Gdk.Window owner_get (Gdk.Atom selection);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--snip--
Compilation failed: 942 error(s), 0 warning(s)
Is there some way of specifying not to include gtk+-2.0 or of making valac ignore these errors?
Without having access to your source code or build environment (assuming you're not merely typing the valac command directly), it's tough to troubleshoot this. Using a dead-simple test.vala with Vala 0.12.1, it builds fine on my system.
In the past I've seen bad Vala environments due to old versions of Vala (and its support files) lurking around. I recommend uninstalling Vala 0.12.1 completely, then going through /usr for any remnants. An easy and thorough way (although time-consuming) is to do this:
$ find /usr -name "*vala*"
$ find /usr -name "*.vapi"
Remove anything that's obviously not part of another package. (Note that some packages install their own VAPIs, like libgee.) Then reinstall Vala 0.12.1 and see if the problem persists.
What version of vala? I fear it must be something messed up in your distribution. Can you paste the contents of /usr/share/.../gtk+-3.0.deps?
Also try using valac --verbose so that you see all the vapis being loaded. For each vapi, look the relative .deps file and check whether there is a gdk-2.0 lying around.
Related
I am trying to create a library in rust to be used with rust executables. In C you can just create your .a or .so (or .lib or .dll on windows) and use tools like CMake to link everything, however rust does not seem to have this kind of infrastructure?
It is possible to make an executable with cargo (cargo new ) and create a library by adding the --lib flag (cargo new --lib), but then how would you use the resulting .rlib file (from the library cargo project)? I managed to link the .rlib file as follows:
rustc main.rs --extern foo=libfoo.rlib
and that works beautifully, though, I am not interested in writing a thousand rustc commands to build the final executable (which depends on the .rlib) if there is cargo that can do that for you. I tried working with a build script (which works perfectly for any C library, static or dynamic), but if I try it with the .rlib file, cargo says that it cannot find "foo" (-lfoo), the build script:
fn main() {
println!("cargo:rustc-link-search=.");
println!("cargo:rustc-link-lib=foo");
}
I tried replacing the path (search) to different directories (whilst also moving the .rlib file to the correct directory), also tried different combinations of libfoo, libfoo.rlib, ... (note that for the C libaries, foo is sufficient).
So my question really is: How can you create a rust library for private use, and how do you use it with a rust executable in a proper way, avoiding manual rustc commands? Are there tools that do this? Am I missing something in the build script? Perhaps there exists something like CMake for rust?
I suppose it is possible to just create a C interface over the rust code and compile another C project as that does work with cargo.
I do NOT want to publish the code to crates.io as I want this library strictly for private use.
Cargo does not support using pre-compiled .rlibs. Cargo is designed to compile programs fully from source (not counting native libraries).
How can you create a rust library for private use … I do NOT want to publish the code to crates.io as I want this library strictly for private use.
To use a private library, you write a dependency using a path or git dependency (or use a private package registry, but that's more work to set up).
[dependencies]
my-lib-a = { path = "../my-lib-a/" }
my-lib-b = { git = "https://my-git-host.example/my-lib-b", branch = "stable" }
Your private library is now compiled exactly like a “public” one.
I am trying to build libboost, 1.70.0.
I've already compiled ICU4C, and installed it locally at my $HOME/usr. I have it build icu-config as well in order to help finding it.
I have $HOME/usr/lib in my LD_LIBRARY_PATH environment variable, and I have $HOME/usr/bin in my PATH.
I am running bootstrap this way:
./bootstrap.sh --with-icu=$HOME/usr/ --prefix=$HOME/usr/
The output suggest that icu will be enabled. And the supplied path is saved in bjam configuration.
Later, when running
./b2 --reconfigure
it says ICU will not be used:
- bzip2 : yes
- lzma : no
- zstd : no
- iconv (libc) : yes
- icu : no
- icu (lib64) : no
- native-atomic-int32-supported : yes
Although not critical, it is interesting it doesn't find lzma, even it being installed locally too.
I am kind of lost, with no idea what I am missing. Recompiled ICU for a couple of times, tried different approaches I found online, and nothing works. Any help is welcome.
Config.log shows,
In file included from /home/ambs/usr/include/unicode/uversion.h:30:0,
from libs/regex/build/has_icu_test.cpp:12:
/home/ambs/usr/include/unicode/umachine.h:340:13: error: char16_t does not name a type
typedef char16_t UChar;
^
In file included from libs/regex/build/has_icu_test.cpp:12:0:
/home/ambs/usr/include/unicode/uversion.h:173:55: error: UChar does not name a type
u_versionFromUString(UVersionInfo versionArray, const UChar *versionString);
^
as well as other similar errors. I am (well, I think I am) compiling with the same compiler (that isn't in a standard path, too, but is in my path).
While I am not understanding why bjam is not detecting correctly the compiler, if I use:
./bjam cxxflags='-std=c++11'
then, not just I have icu, as I have C++11 features detected.
I'm trying to get Libcurl working in my VC++ project on VS2013 Community. I've been toiling with this for many hours, and I've tried essentially everything on Stack and Google about it, to no avail.
My most recent attempt was sparked by this answer, that mentions libcurl as a Nuget package. This is good, because it comes with all of the .lib files required. I have however run into the same problem as this fellow, in that I'm getting a linker error.
I'm importing the following libraries as 'Additional Dependencies' in the Project Configuration settings under Linker -> Input:
libcurl.lib;libeay32.lib;ssleay32.lib;Ws2_32.lib;libssh2.lib;zlib.lib;wldap32.lib;
Obviously, each one of these .lib files is in a different directory inside the nuget package folder inside the project folder, so under Linker -> General my 'Additional Library Directories' is set to:
"PATHTOPROJECT\packages\curl.7.30.0.2\build\native\lib\v110\x64\Release\static";
"PATHTOPROJECT\packages\zlib.1.2.8.1\build\native\lib\v110\Win32\Release\static\cdecl";
"PATHTOPROJECT\packages\openssl.1.0.1.21\build\native\lib\v110\x64\Release\static\cdecl";
"PATHTOPROJECT\packages\libssh2.1.4.3.1\build\native\lib\v110\x64\Release\static\cdecl";
I am trying to use static libraries, because I don't want to drag .dll's with my project executable if I can avoid it. It's also worth noting that my most recent attempt at using libcurl also includes SSL and whatnot, but I don't actually need those extras. Really, I just need a static libcurl library, but I can't find or compile one it seems.
In my code, I'm also using this include: #include "curl/curl.h"
I've also added the Additional Include directory correctly under 'Additional Include Directories' under C/C++ -> General:
PROJECTPATH\packages\curl.7.30.0.2\build\native\include
Now, this all compiles fine as long as I don't try and use curl in the project code.
So, the errors when I do try and use curl in the code:
CURL *curl;
curl = curl_easy_init();
That piece of code generates these errors:
1>Main.obj : error LNK2028: unresolved token (0A000453) "extern "C" void * __cdecl curl_easy_init(void)" (?curl_easy_init##$$J0YAPAXXZ) referenced in function "private: class System::String ^ __clrcall Project::Main::CurlRequest(class System::String ^,class System::String ^,class System::String ^,class System::String ^)" (?CurlRequest#Main#Project##$$FA$AAMP$AAVString#System##P$AAV34#000#Z)
1>Main.obj : error LNK2019: unresolved external symbol "extern "C" void * __cdecl curl_easy_init(void)" (?curl_easy_init##$$J0YAPAXXZ) referenced in function "private: class System::String ^ __clrcall Project::Main::CurlRequest(class System::String ^,class System::String ^,class System::String ^,class System::String ^)" (?CurlRequest#Main#Project##$$FA$AAMP$AAVString#System##P$AAV34#000#Z)
There is of course more to my curl using code, but that bare minimum shows the basics of the linking error. What can I do to fix this? As I mentioned before I've tried a whole range of solutions, some of which I'll list below:
Many answers to the questions regarding problems using libcurl in VS projects mention downloading libcurl from http://curl.haxx.se/latest.cgi?curl=win32-devel-msvc, but that link doesn't work as of now, so I can't use it.
More answers say to just compile libcurl from source. The source comes with .vcproj files, none of which compile for me without hundreds of errors, so that's out.
Solved.
This Github project is a .bat file that downloads the libcurl source, compiles it, and makes the libraries (both static and dynamic). Importing the static library created by this (libcurl_a.lib) and using it in my project along with the include directory has worked.
I'll leave this question with an unaccepted answer in case someone can provide other helpful steps that would have fixed the problem I had in using the nuget package installation.
Finally.
There appears to be a Ant / jni.h problem (for my setup) with LibusbJava. I get the following error when setting up LibusbJava by running
ant linux
in CentOS 6.3 as root (quick and dirty test, thanks for those concerned about user level =0). I will redo with proper restrictions as shown on a libusbjava reference after reflection when first install works. LibusbJava, is a Java wrapper for the libusb library.
The output starts out like this:
[root#somebox LibusbJava]# ant linux -lib $JAVA_HOME/include -lib $JAVA_HOME/include/linux
Buildfile: build.xml
clean:
Build LibusbJava Test Linux:
Build LibusbJava Test:
[echo] Building Library for unit tests:
[exec] /.../libusbjava/trunk/LibusbJava/LibusbJava.cpp:27:17: error: jni.h: No such file or directory
[exec] /.../libusbjava/trunk/LibusbJava/LibusbJava.cpp:34:26: error: test/CuTest.h: No such file or directory
`...`
as it was not set on my system. It appears that jni.h is a header called by C++ code, which I had to add to the LibusbJava.cpp file. This is the new include, /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/include/jni.h. I then get an error with jni.h not being able to fine jni_md.h which is an include in jni.h #include "jni_md.h".
Clearly this is not the right approach, so perhaps I need a correct Ant reference, but I cannot seem to do it with a -lib switch. Besides, this just creates thousands of jni.h file errors during the Ant build attempt.
How can I fix this problem?
Notes: I've set$JAVA_HOME up like JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64 and javac and java work fine.
New discovery... after helpful questions which guided me, I am much closer to successful compilation.
When I install LibusbJava and manually install all the library references in build.xml there is still an error compiling the LibusbJava based on a memset error. I see memset patches for libusb that appeared in 2007 and it's unclear how to use or if they relate. Investigating... Hints, comments and questions welcome. My most sincere thanks for the help thus far.
[exec] /.../libu/libusbjava/trunk/LibusbJava/objects/Usb_Device.cpp: In function ‘void Usb_Device_disconnect(JNIEnv*)’:
[exec] /.../libu/libusbjava/trunk/LibusbJava/objects/Usb_Device.cpp:88: error: ‘memset’ was not declared in this scope
[antcall] Exiting /.../libu/libusbjava/trunk/LibusbJava/build.xml.
BUILD FAILED
but I find no referece to an include string.h or cstring. The header of Usb_Device.cpp mentions it is a C++ Stub for the java class of a java class ch.ntb.inf.libusbJava.Usb_Device. which only has this include #include "Usb_Device.h" which also does not appear to have a string include. Perhaps just insertion of#include`?
I am trying to get PhysX working using Ubuntu.
First, I downloaded the SDK here:
http://developer.download.nvidia.com/PhysX/2.8.1/PhysX_2.8.1_SDK_CoreLinux_deb.tar.gz
Next, I extracted the files and installed each package with:
dpkg -i filename.deb
This gives me the following files located in /usr/lib/PhysX/v2.8.1:
libNxCharacter.so
libNxCooking.so
libPhysXCore.so
libNxCharacter.so.1
libNxCooking.so.1
libPhysXCore.so.1
Next, I created symbolic links to /usr/lib:
sudo ln -s /usr/lib/PhysX/v2.8.1/libNxCharacter.so.1 /usr/lib/libNxCharacter.so.1
sudo ln -s /usr/lib/PhysX/v2.8.1/libNxCooking.so.1 /usr/lib/libNxCooking.so.1
sudo ln -s /usr/lib/PhysX/v2.8.1/libPhysXCore.so.1 /usr/lib/libPhysXCore.so.1
Now, using Eclipse, I have specified the following libraries (-l):
libNxCharacter.so.1
libNxCooking.so.1
libPhysXCore.so.1
And the following search paths just in case (-L):
/usr/lib/PhysX/v2.8.1
/usr/lib
Also, as Gerald Kaszuba suggested, I added the following include paths (-I):
/usr/lib/PhysX/v2.8.1
/usr/lib
Then, I attempted to compile the following code:
#include "NxPhysics.h"
NxPhysicsSDK* gPhysicsSDK = NULL;
NxScene* gScene = NULL;
NxVec3 gDefaultGravity(0,-9.8,0);
void InitNx()
{
gPhysicsSDK = NxCreatePhysicsSDK(NX_PHYSICS_SDK_VERSION);
if (!gPhysicsSDK)
{
std::cout<<"Error"<<std::endl;
return;
}
NxSceneDesc sceneDesc;
sceneDesc.gravity = gDefaultGravity;
gScene = gPhysicsSDK->createScene(sceneDesc);
}
int main(int arc, char** argv)
{
InitNx();
return 0;
}
The first error I get is:
NxPhysics.h: No such file or directory
Which tells me that the project is obviously not linking properly. Can anyone tell me what I have done wrong, or what else I need to do to get my project to compile? I am using the GCC C++ Compiler. Thanks in advance!
It looks like you're confusing header files with library files. NxPhysics.h is a source code header file. Header files are needed when compiling source code (not when linking). It's probably located in a place like /usr/include or /usr/include/PhysX/v2.8.1, or similar. Find the real location of this file and make sure you use the -I option to tell the compiler where it is, as Gerald Kaszuba suggests.
The libraries are needed when linking the compiled object files (and not when compiling). You'll need to deal with this later with the -L and -l options.
Note: depending on how you invoke gcc, you can have it do compiling and then linking with a single invocation, but behind the scenes it still does a compile step then a link step.
EDIT: Extra explanation added...
When building a binary using a C/C++ compiler, the compiler reads the source code (.c or .cpp files). While reading it, there are frequently #include statements that are used to read .h files. The #include statements give the names of files that must be loaded. Those exact files must exist in the include path. In your case, a file with the exact name "NxPhysics.h" must be found somewhere in the include path. Typically, /usr/include is in the path by default, and so is the current directory. If the headers are somewhere else such as a subdirectory of /usr/include, then you always need to explicitly tell the compiler where to look using the -I command-line switches (or sometimes with environment variables or other system configuration methods).
A .h header file typically includes data structure declarations, inline function definitions, function and class declarations, and #define macros. When the compilation is done, a .o object file is created. The compiler does not know about .so or .a libraries and cannot use them in any way, other than to embed a little bit of helper information for the linker. Note that the compiler also embeds some "header" information in the object files. I put "header" in quotes because the information only roughly corresponds to what may or may not be found in the .h files. It includes a binary representation of all exported declarations. No macros are found there. I believe that inline functions are omitted as well (though I could be wrong there).
Once all of the .o files exist, it is time for another program to take over: the linker. The linker knows nothing of source code files or .h header files. It only cares about binary libraries and object files. You give it a collection of libraries and object files. In their "headers" they list what things (data types, functions, etc.) they define and what things they need someone else to define. The linker then matches up requests for definitions from one module with actual definitions for other modules. It checks to make sure there aren't multiple conflicting definitions, and if building an executable, it makes sure that all requests for definitions are fulfilled.
There are some notable caveats to the above description. First, it is possible to call gcc once and get it to do both compiling and linking, e.g.
gcc hello.c -o hello
will first compile hello.c to memory or to a temporary file, then it will link against the standard libraries and write out the hello executable. Even though it's only one call to gcc, both steps are still being performed sequentially, as a convenience to you. I'll skip describing some of the details of dynamic libraries for now.
If you're a Java programmer, then some of the above might be a little confusing. I believe that .net works like Java, so the following discussion should apply to C# and the other .net languages. Java is syntactically a much simpler language than C and C++. It lacks macros and it lacks true templates (generics are a very weak form of templates). Because of this, Java skips the need for separate declaration (.h) and definition (.c) files. It is also able to embed all the relevant information in the object file (.class for Java). This makes it so that both the compiler and the linker can use the .class files directly.
The problem was indeed with my include paths. Here is the relevant command:
g++ -I/usr/include/PhysX/v2.8.1/SDKs/PhysXLoader/include -I/usr/include -I/usr/include/PhysX/v2.8.1/LowLevel/API/include -I/usr/include/PhysX/v2.8.1/LowLevel/hlcommon/include -I/usr/include/PhysX/v2.8.1/SDKs/Foundation/include -I/usr/include/PhysX/v2.8.1/SDKs/Cooking/include -I/usr/include/PhysX/v2.8.1/SDKs/NxCharacter/include -I/usr/include/PhysX/v2.8.1/SDKs/Physics/include -O0 -g3 -DNX_DISABLE_FLUIDS -DLINUX -Wall -c -fmessage-length=0 -MMD -MP -MF"main.d" -MT"main.d" -o"main.o" "../main.cpp"
Also, for the linker, only "PhysXLoader" was needed (same as Windows). Thus, I have:
g++ -o"PhysXSetupTest" ./main.o -lglut -lPhysXLoader
While installing I got the following error
*
dpkg: dependency problems prevent configuration of libphysx-dev-2.8.1:
libphysx-dev-2.8.1 depends on libphysx-2.8.1 (= 2.8.1-4); however:
Package libphysx-2.8.1 is not configured yet.
dpkg: error processing libphysx-dev-2.8.1 (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
*
So I reinstalled *libphysx-2.8.1_4_i386.deb*
sudo dpkg -i libphysx-2.8.1_4_i386.deb