I am trying to modify the behaviour of the DNS lookup functions in Linux for my project by setting it to write a random string in a file as a test.
Linux use some DNS resolver functions, mainly gethostbyname. Looking forward, I found out that the resolver functions are within the glibc6 library. So, I downloaded it, compiled, generating the libresolv.so, libnss_dns.so dynamic libraries. Then, I replaced the existing ones on my system, at /usr/lib/x86_64-linux-gnu/.
Note: I found out these libraries are the ones that resolves queries by modifying gethostbyname code and compiling again. Then, I saw which dynamic libraries changed.
By creating a program that uses res_query directly (a resolver function) and compiling with -lresolv, it works (I used ldd command and it uses the resolver library I created). But, using gethostbyname directly from the code, using wget or browsing the web I can't get it right.
What am I doing wrong?
I discovered what should I do:
Firstly, the function called isn't gethostbyname. It is _nss_dns_gethostbyname3_r, defined in resolv/nss_dns/dns-host.c. Looking at the source I realized that this function called another one to resolve DNS names, __libc_res_nsearch, defined in resolv/res-query.c. So this is the function! I added some file writting commands there and it worked like a charm. I called it from C code using gethostbyname, used wget and Firefox, all worked. When you compile the code you should replace the libresolv.so of your system by the new one.
Note: my glibc version is 2.19.
I hope this helps someone.
Related
I am trying to load a dynamic library <libname>.so which is present in current directory as well as in /use/lib, /lib, /lib32. but program is not able to find it to any of these path.
I am running a pascal program and it has this method
LibHandle := LoadLibrary( PAnsiChar(Trim('./libtrdp.so')) );
it fails and gives error.
"This binary has no dynamic library support compiled in.
Recompile the application with a dynamic-library-driver in the program uses clause before other units using dynamic libraries.
Runtime error 235 at $0805F292"
if anyone is aware of this issue then please let me know as I have searched on the internet but could not find the answer.
Note: I am running this program on Linux machine.
Add unit dynlibs to the uses clause.
On Linux, loadlibrary is an empty stub that gets filled when you add dynlibs. This is done to keep the base runtime libc+dl free.
I am using Asio in a Rcpp package, and am therefore using the package AsioHeaders.
I have added BH and AsioHeaders in the "LinkingTo" part of the DESCRIPTION file of my package. I have also added comments
// [[Rcpp::depends(BH)]]
// [[Rcpp::depends(AsioHeaders)]]
in my code. So normally, the linking should be fine when compiling the package.
And it is when I compile it on Linux. But when trying to compile it on Windows, I get linking errors that are solved by linking -lws2_32 and -lwsock32.
I am thus wondering, whether I should edit the Makevars file so that these are linked on Windows but ignored on Linux, or if I have done something wrong using AsioHeaders?
AsioHeaders maintainer here. Quick questions:
Which version of AsioHeaders? It just updated at CRAN. Is this a change from the new version (which would suprise me ...)?
Make sure you are not accidentally using Asio functionality from Boost which will require linking. See the three packages using AsioHeaders.
If your package is truly header-only then LinkingTo: is all you need. R will find the header directories for you. In particular, you do not need link instructions in src/Makevars* because, well, header-only.
Also, you probably meant // forward slashes for your C++ comments above...
I have a 7 year old game that a friend built & I have very little of the source code left.
It works perfect on CentOS 4.8 and below, so I'm thinkin' it's a TLS error. I transfered a new folder with all the CentOS 4.8 libraries the program called to the new one... I'm trying to load the old libraries it called for in ldd specifically to that program,. This is what I'm trying:
LD_PRELOAD="/glibs/ld-linux.so.2 /glibs/libc.so.6 /glibs/libgcc_s.so.1 /glibs/libm.so.6 /glibs/libpthread.so.0 /glibs/libstdc++.so.5 /glibs/libz.so.1 /glibs/libxml2.so.2" /home/g/gameserver
I keep getting a Segmentation Fault error, does anyone know why? Maybe I don't fully understand what LD_PRELOAD does or something. How would I be able to load old libraries without messing up the originals? Thanks in advance!
LD_PRELOAD is more used to override a functionality in a library before the normal ones get used (e.g. custom malloc, socksify all sockets etc). What you probably need is to put all your old libraries into their own directory and then set LD_LIBRARY_PATH so that it attempts to find the library first in this directory.
I have a dynamic library that changes name across major versions i.e. version 3 was named lib3 and version 4 is named lib4, and so on.
I need to provide a shim lib3 that will allow an old application to use the new library in a transparent way, and most of the exported functions did not change across versions, so a forwarding DLL looks pretty good for the task on Windows.
Is there something equivalent on Linux/Unix?
The Linux equlivalent is rather easy. You can just use a symbolic link. For example, lib4 is the new library version, then you can create the following symbolic link:
ln -s lib4 lib3
Now, every time a program will need lib3 will automatically load lib4 as long as the interface
exported by the new version is equal to the old version, the program will not notice the difference.
I hope this helps. Let me know if you need more info.
I am trying to build an application with OpenSync 0.4 (0.3.9 indeed) dependency.
In the project's configure.ac the opensync library is written as libopensync1. However, this doesn't build on my Gentoo system. Changing libopensync1 to libopensync does fix the issue for me.
I searched with Google and found that libopensync1 is used in some distributions, while libopensync in others. So how to resolve this issue in configure.ac?
Thanks.
The macro AC_SEARCH_LIBS does what you need. (There is much heated debate about whether or not pkg-config should ever be used. If you choose to rely on it, ptomato gives a reasonable approach.) Simply add this to your configure.ac:
AC_SEARCH_LIBS([osync_mapping_new],[opensync1 opensync],[],
[AC_MSG_ERROR([can't find opensync])])
This will first look for a library named opensync1; if
it doesn't find that, it will look for opensync.
The primary drawback of using pkg-config is that most projects that
rely on it do not actually check if the data provided by the .pc
file is reliable, so configure may succeed but a subsequent build
will fail. It is always possible for a user to set PKG_CONFIG=true
when running configure and completely eliminate all of the data
provided by any associated .pc files, setting LIBS, CFLAGS, etc by
hand the 'old-fashioned' way.
The primary drawback of not using pkg-config is that the user
has to set LIBS, CFLAGS, etc. the old-fashioned way. In practice,
this is pretty trivial, and all pkg-config has done is move the
data from a single CONFIG_SITE file to separately maintained
.pc files for each package.
If you do use PKG_MODULE_CHECK, follow it up with a call to
AC_CHECK_LIB or AC_SEARCH_LIBS to validate the data in whatever
.pc file was located by PKG_CHECK_MODULES
I'm assuming that the place at which this occurs inside your configure.ac is inside a PKG_CHECK_MODULES call.
Looking at the libopensync sources, it seems that libopensync1 is the newer name, and libopensync is the old name. So, we'll use pkg-config macros to look for the newer name unless it doesn't exist.
Put this in your configure.ac:
# Check if libopensync1 is known to pkg-config, and if not, look for libopensync instead
PKG_CHECK_EXISTS([libopensync1], [OPENSYNC=libopensync1], [OPENSYNC=libopensync])
Then later in your PKG_CHECK_MODULES call, replace libopensync1 with $OPENSYNC.