I am using the POSIX call nftw() for traversing a directory structure. The directory structure is flat - only 4 files and no subdirectories.
However when I call nftw() a lot of times on this flat directory then I get an error message after a while:
"too many open file handles".
It turned out that this happens when the flag FTW_CHDIR is used.
Would you agree that it is a bug in the Linux implementation of nftw() ?
UPDATE
A fix is now available in the glibc repositories.
here are some links to the source code I have used for testing:
main.cpp: http://sourceware.org/bugzilla/attachment.cgi?id=4586&action=view
Makefile: http://sourceware.org/bugzilla/attachment.cgi?id=4587&action=view
UPDATE
MacOS-X is also hit by the bug
Solaris9, Solaris10 and AIX 5.3 do not have the bug
For me it looks like there is really something wrong with the nftw implementation on linux.
I have filed a bug report, see here
UPDATE: A fix is available in the glibc repositories now.
It has the same behaviour on Mac OS 10.6.2. So probably somehow part of the specification, though I don't see how exactly.
Regarding Mac OS: bugreport submitted to Apple as radar #7640283. (No hyperlink possible, unfortunately.)
Related
I try to develop a thirdparty unixODBC driver, it is a secondary development based on the original file libodbc.so.2.0.0.
so I want to rename 'libodbc.so.2.0.0' to 'libodbc.so.2.0.0_renamed'. And soft link my dynamic library file to libodbc.so.2.0.0.
But I found an issue bothering me, when I rename native file and run 'sudo ldconfig', the file named 'libodbc.so.2' automatically linked to the renamed file 'libodbc.so.2.0.0_renamed', as below:
I could not understand that:
why it occurs;
how to appropriately replace the library.
I don't have enough ackownledge about linux, so that I failed to get any keyword to search and deal with it.
Could you help me, thank you very much!
Shared objects under GNU/Linux follow a specific version naming scheme, which is known by the loader (and OS component, actually part of libc framework) to determine if a newer library is retro-compatible with some older version to which a binary was originally linked against. By adding the renamed suffix, you are violating the convention and the dynamic linking system is getting confused. You should renamed as suggested by #Bodo above.
In addition, perhaps rather than using rename, you might consider using the very versioning scheme. From GNU Build System (aka Autotools) manual, the version cheme is like it follows:
Versioning: CURRENT:REVISION:AGE
CURRENT The latest interface implemented.
REVISION The implementation number of CURRENT (read: number of bugs fixed...)
AGE The number of interfaces implemented, minus one.
The library supports all interfaces between CURRENT − AGE and CURRENT.
If you have
not changed the interface (bug fixes) CURRENT : REVISION+1 : AGE
augmented the interface (new functions) CURRENT+1 : 0 : AGE+1
broken old interface (e.g. removed functions) CURRENT+1 : 0 : 0
Therefore a possible history of your lib might be:
1:0:0 start
1:1:0 bug fix
1:2:0 bug fix
2:0:1 new function
2:1:1 bug fix
2:2:1 bug fix
3:0:0 broke api
3:1:0 bug fix
4:1:1 bug fix
5:0:0 broke api
You might, for instance, call the older and newer versions of libodbc.so.x.y.z, according to your needs. Just an idea.
I didn't work during the last two months on one of my projects, today I've compiled it and I tried to run it, but when I try to run it I got this error :
./a.out: error while loading shared libraries: libGLEW.so.1.10: cannot open shared object file: No such file or directory
so I did ldd a.out | grep "GLEW" and got :
libGLEW.so.1.11 => /usr/lib/libGLEW.so.1.11 (0xb7380000)
libGLEW.so.1.10 => not found
locate libGLEW returns :
/usr/lib/libGLEW.so
/usr/lib/libGLEW.so.1.11
/usr/lib/libGLEW.so.1.11.0
/usr/lib/libGLEWmx.so
/usr/lib/libGLEWmx.so.1.11
/usr/lib/libGLEWmx.so.1.11.0
I don't understand why and how my project can link 1.11 and 1.10 at the same time, I check my CMakeLists.txt nothing specify to use 1.10 or 1.11, so from where can come from my problem ? If you need more information I can add some, but right now, I don't know what kind of informations can be usefull to fix this issue. I guess the problem appeared after an update of my OS (archlinux)
To the loader, these are all just file names. It has no concept of versioning.
My guess is that the situation arose because 1.11 is a thin layer perhaps to patch a bug or enhance functionality and is suppose to mostly use the 1.10 version.
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'm compiling dalvik on Android 4.1 with both host and target set to x86. The make command is:
make dalvikvm core ext framework android.policy services
However, there are multiple compiled binaries:
out/host/linux-x86/bin/dalvikvm
out/host/linux-x86/bin/dalvik
out/target/product/generic_x86/system/bin/dalvikvm
out/target/product/generic_x86/symbols/system/bin/dalvikvm
But the target versions don't work. When run, they show:
bash: ./dalvikvm: No such file or directory
This error is so strange that, I mean, the file is just there.
Could anyone please tell me which one is the compiled result? I mean, if I make some modification to dalvik source, which one will contain the modified result? Thank you.
This is almost certainly a linkage issue. The host version is linked against the normal host libc, but the target versions are linked against the android libc that lives in /system/lib on the device, which your host ld knows nothing about.
You might try something like:
LD_LIBRARY_PATH=<android_root>/out/target/product/generic_x86/system/lib out/target/product/generic_x86/symbols/system/bin/dalvikvm
Although I'm not entirely sure if that would work
All was right in the world until I upgraded to Xcode 4 a few days ago. Since then I've had endless problems getting things to work as they should. And I have a crucial update I need to release. I've tried every permutation of settings I can think of, restarted, reinstalled Xcode, reverted to old versions of my files, everything.
My project links to three static libraries, contained in three other projects. I have used the standard processes to link libraries (drag the project files into mine, add their products as target dependencies, add the lib---.a files to the Link Binary With Libraries phase). And actually, I have no problem compiling with the Debug Build Configuration, either for the simulator or my test device.
Where everything goes sideways is when I compile with the Release Build Configuration, or when I try to Archive. I've gotten many different errors depending on my settings, but most are variations on this:
ld: warning: ignoring file
[...]/Build/Products/Debug-iphonesimulator/libGDataTouchStaticLib.a,
file was built for archive which is
not the architecture being linked
(armv6) Undefined symbols for
architecture armv6:
"_OBJC_CLASS_$_GDataSpreadsheetData",
referenced from:
objc-class-ref in ExportViewController.o
I can't understand why it's even looking at Products in the Debug-iphonesimulator directory (I swear, everything I'm linking to reveals itself in the Finder to be in the proper Release-iphoneos directory).
I have put a ridiculous number of hours into fixing this, really need help! Thank you!
Please check this question and answer. I encountered same problem and fixed it.
Xcode4 Linking Problem. File was built for archive which is not the architecture being linked (arm6)
I solved this problem by copying the .a lib files from the Release-iphoneos directory to the Debug-iphonesimulator directory so that the correct files would be found even though Xcode was looking in the wrong directory.
However, then I encountered the problem raised here of a multi-application bundle -- and the solution given didn't work for me. Finally gave up and reinstalled Xcode 3. Compiled, archived, and uploaded to the App Store in 20 minutes. Will be some time, and several dot-releases, before I give Xcode 4 another shot.
You may have -DGDATA_REQUIRE_SERVICE_INCLUDES=1 enabled in your other C flags for the GDataTouchStaticLib target. If so, add the service you need, in this case, spreadsheets, by adding -DGDATA_INCLUDE_SPREADSHEET_SERVICE=1 to your Other C Flags. Or if you don't want GData to require service includes (which will build everything into the static lib, not just what you need), just remove the DGDATA_REQUIRE_SERVICE_INCLUDES flag.