CMAKE link shared library that has version information - makefile

I upgraded ORACLE and the library no is called libocci.so.12.1.
When I compile via (cmake.. and make) the linking fails. It does not find libocci.
My previous version of occi was named libocci.so.
How to I resolve this without creating soft links?

If you use something like FindOcci.cmake module then it should successfully locate the library when you re-run CMake. If it doesn't, take a look at its source and fix it.
Alternatively, if you just use the hardcoded library name like target_link_libraries(myapp occi), you need to search for it first. Take a look at find_library() command.

Related

Linking Mac Frameworks using Premake and GNU Make

I have a "cross platform" application that uses two code repositories at the moment, maintained relatively independently, and built with VS / Xcode depending on the target platform (win or mac respectively). I fell in love with Premake after using it on a few previous projects and am trying to pull all of my code for this application together into a single cross-compilable codebase.
I don't want to rely on Xcode, and instead want any developer to be able to build on Mac using either Xcode or gmake. I have a non-standard framework that I want to link to and include in the repository (it won't be located in /Library/Frameworks or any of the default mac framework search paths). I've added the framework file in a directory in my project /lib/TheFramework.framework. My premake file contains the following under the project definition:
includedirs {".", "lib", "lib/TheFramework.framework/Headers"}
libdirs {"lib"}
links {"TheFramework.framework"}
When I compile, (running $ premake5 gmake and then $ make), I get a header file not found error. Is there something wrong with my search paths? Am I missing a path or a flag somewhere?
Thanks!
Before looking at what you need to do with premake, let's first look at what needs to happen under the hood.
When compiling a mac program with a non-standard framework on gcc or clang (which is what your resulting make file does) it is necessary to do two things:
Specify the name of the framework, via -framework TheFramework - This is what premake does when you provide it with links {"TheFramework.framework"
Specify the location of the framework, via -F /Path/To/Framework/ - This is currently not being handled automatically by premake.
I've made a simple test c program that uses the SDL2 framework and compiled it with gcc: https://gist.github.com/JohannesMP/6ff3463482ebbdc82c2e - notice how when I leave off the -F /... flag I get an error that is probably similar to what you described.
So what is happening is, although you are providing premake with the include dir, premake will not add that the proper -F flag.
One way around this is to do the following:
configuration {"macosx", "gmake"}
buildoptions {"-F /Path/To/Framework"}
linkoptions {"-F /Path/To/Framework"}
(See here for an example project: https://gist.github.com/JohannesMP/9a9b5263c127103f1861#file-premake5-lua-L24-L26 )
In premake5 this will blindly append the code provided to both the build step as well as the link step. It is necessary to do it both for build as well as link.
Just keep in mind that, because premake doesn't process or check the build/link options for being valid, a user will receive an error if the provided path doesn't exist on their machine. For example while you might have a framework in your user-specific directory ~/Library/Frameworks, since that folder doesn't exist by default another user might be using the global /Library/Frameworks instead, and when they try to compile your premake project with gmake they will get a warning:
ld: warning: directory not found for option '-F/Users/<NAME>/Library/Frameworks'
At this point, it seems that there is no 'safe' way to get premake5 to try to include the framework path, but that may change in the future.
Check out this issue I posted on the premake repo: https://github.com/premake/premake-core/issues/196

How to compile QtWebKit on Qt5?

I try to compile QtWebKit on Qt5 but I have a problem. Actually I implement next command "d:\qt_5.0.2\qtwebkit qmake" after that
I see "Running configure test..." but at all after that I have a problem "pkg-configure isn't inside or outside command using app or package file"
And then i get the error ->> "Project ERROR: WebKit requires SQLite. Either make it available via pkg-config, set $SQLITE3SRCDIR or build WebKit under qt5.git."
Exactly what the message tells you: you need sqlite sources to compile QtWebKit. Given you're under Windows, we can exclude the pkg-config way.
You have a copy of sqlite sources inside the qtbase repository, so you can do in your prompt
SET SQLITE3SRCDIR=D:\path\to\qtbase\src\3rdparty\sqlite
and then qmake and make as usual.
(Note that you're not building from qt5.git as the message suggest, but module by module. That has its pros and its cons. Having to manually manage module (inter)dependencies is one of the cons, as you've just figured out.)

Adding library to Xcode project

I'd like to add the libevent library to my Xcode project. I want to include it in the executable, because libevent isn't installed by default on Mac OS X.
I can compile the library from source using ./configure && make. I expected to find a .a library file, but there isn't. What do I do then? What files are relevant and how do I add them to Xcode?
Sorry for this very basic question, but I don't even know where to start.
First off, let's find out if your library truly got built. In the terminal, type in cd / and then find . -name libevent\* -print and see if the path for your libevent.a file actually appears.
If you can't find it, try running sudo make install from the top level of the library source code and then the library may end up getting installed in /usr/local/lib or some other appropriate place.
Once you do find the library, you can drag & drop it into your Project's list of Files in Xcode. Or you can include -levent in the link settings for your project.
Note that Xcode has this nasty "feature" that if it sees both dynamic and static versions of a library, it will always link against the dynamic one, even you specify the static one (.a) in your project. There's no way to override this "feafure" and you have to move or delete the dynamic one out of the library search paths.

glibc Linux based

I am currently using ubuntu 9.10 with the glibc version 2.11.1-0,
well i am doing a project, that i want to test with the another version of glibc that is 2.5-58, i wanted to know following things regarding this:
How to compile the version of 2.5-58, however keeping the previous version?
How to link the existing programs with the binaries of newer version of glibc?
I would be highly obliged if anybody can help me!!!
Thanks
If you want to manually compile another version of glibc, then I suggest you configuring (./configure script run) it with --prefix option to install not to /lib, /usr/lib but to /home/mehul/glibc2.5.58test/lib and /home/mehul/glibc2.5.58test/usr/lib
But compiling of glibc is not very easy thing, so another way is to get glibc 2.5-58 in compiled form from other linux and manually copy it to some subdirectory. Then you can override library search path of gcc and recompile your lib with libc from subdirectory.
Or you can use LD_LIBRARY_PATH to override library search path of compiled binary to use older glibc like this:
$ LD_LIBRARY_PATH=/home/mehul/glibc2.5.58test/lib /path/to/your/application
If you know that that version of libc is used in an older ditribution, you could install that distribution in a chroot/scratchbox/kvm/qemu/livecd or other such system for testing and building. Or there may be some other build farm type solution. Then you'll have an authentic system to test on that will not mess up your up to date one. It'll also be repeatable if you keep that system image.
If this isn't about a specific older release, why on earth would you want to test against a specific very old libc?

Statically linking to a dynamic library. glibc

So. I have a problem where I have two versions of GCC on a machine.
3.4.6 and 4.1
This is due to some dependency issues with a new piece of software. (requires glibc 4.1)
When I go to link this new software with the 4.1 libraries it links fine. However, when it comes to executing the software it can't find the library, because it is looking at 3.4.6 in my LD_LIBRARY_PATH. If I set LD_LIBRARY_PATH to the 4.1 lib it blows up the shell,among killing other things, because the 3.4.6 libraries are used for that.
Its a bit of a catch 22.
Is there any way that at link time I can give an absolute path to that shared library without using the LD_LIBRARY_PATH?
This way I can hopefully have both versions, but only use 4.1 for this specific application?
You mean an absolute path that's used when the program is started and that's favored when looking for libraries? rpath is exactly that. It will overwrite the default search path and stuff set in LD_LIBRARY_PATH. Just tell gcc to pass it through to the linker:
g++ -Wl,-rpath,/usr/lib/my_4.1 -omy_binary *.cpp
You can make it show you the search processing (use help to make it give you more options):
[js#HOST2 cpp]$ LD_DEBUG=libs ./a.out
5859: find library=libc.so.6 [0]; searching
5859: search path=/usr/lib/my_4.1/tls/i686/sse2:/usr/lib/my_4.1/tls/i686:
/usr/lib/my_4.1/tls/sse2:/usr/lib/my_4.1/tls:
/usr/lib/my_4.1/i686/sse2:/usr/lib/my_4.1/i686:
/usr/lib/my_4.1/sse2:/usr/lib/my_4.1 (RPATH from file ./a.out)
5859: trying file=/usr/lib/my_4.1/tls/i686/sse2/libc.so.6
5859: ....
5859: search cache=/etc/ld.so.cache
5859: trying file=/lib/libc.so.6 (note: found here!)
5859:
not really an answer to your question, but an alternate solution:
you should be able to fix up your issues by adding your new lib path to /etc/ld.so.conf and running ldconfig as root.
Can't you set LD_LIBRARY_PATH just for the application that needs it?
I.e. instead of setting it globally as an exported variable, run your program as
LD_LIBRARY_PATH=/path/to/4.1/libs my_executabel
?
-k

Resources