FUSE = Filesystem in user space recommends that distros package both a fuse2 and a fuse3 (see here) and indeed they do.
What exactly is the reason for this? Is it just that the init code in fuse3 is different?
The release notes for libfuse 3.0.0 appear comprehensive. Read below the heading 'Changes (since FUSE 2.9)'. Functions have been renamed for clarity, functions dropped and parameters tidied up. Here are a few examples from the release notes to give a flavour:
The fuse_lowlevel_new function has been renamed to
fuse_session_new and no longer interprets the --version or --help
options
fuse_loop(), fuse_loop_mt(), fuse_session_loop() and fuse_session_loop_mt() now return more detailed error codes instead of just -1. See the documentation of fuse_session_loop() for details
There are new fuse_session_unmount and fuse_session_mount
functions that should be used in the low-level API. The fuse_mount
and fuse_unmount functions should be used with the high-level API
only
The fuse_invalidate function has been removed
Installing libfuse2 alongside libfuse3 allows applications using libfuse2 to keep working without needing to be updated straight away.
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 am using Python3.4. I have installed a certain "itunespy" library from GitHub with pip, to work with iTunes API.
(https://github.com/spaceisstrange/itunespy)
I can now access it from console by
import itunespy
Except the library is only searching the US store through iTunes Api, whereas I need to access the UK store. I looked into the code and found I only need to change two lines to fix my problem.
Please can you tell me how I can access and change the source code of an already installed library.
Thank you.
Fork the repository
Clone the forked repository
Make changes and push to your remote (origin, usually)
You may pip install from your fork
I took a look at source code, and:
a) you may obviously change your source code in locally-copied file
b) you may patch these constants in run-time, like adding this type of code to your main:
import itunespy
itunespy.base_search_url = "NEW_VALUE"
itunespy.base_lookup_url = "NEW_VALUE"
c) library API seems to provide country keyword argument, so you do not have to do any of these hacks mentioned above. Simply do:
itunespy.search_track('something', country='UK')
With this keyword argument, searches should work as expected without any modifications of source code.
you really want to change the sourcecode?
How about just change your implementation?
inherit from the class
override/overload their methods with your own
work with your inherited class and their methods
pro: if there are changes in the original library you will take them with you when you update (secure-patches etc.) but your overridden/overloaded methods are still the one you use.
otherwise if you really want to change the source code, take a branch from github and change the sourcecode as you need it like mentioned by dolftax
The ~/.cabal/config stores configuration which cabal-install uses. I wanted to do some hackery on it. (Specifically, having multiple GHC versions installed, I wish to have separate documentation indexes).
I couldn't, however, find any documentation about its' syntax or variables except for what is included in default file. Is there any documentation available?
Edit: I've stated the goal above, but let me add some details: If the same package (eg. GTK) is installed in two versions of GHC they end up in the same documentation index file. I wan't that local documentation index to be separate for each GHC installation. I believe it is possible in some way using documentation directory setting, but there has to be a variable for currently used GHC version. If there isn't one there might be some workarounds available, but I won't be able to say that unless I see the documentation.
This seems to work, although I've only tested it with one version of GHC:
documentation: True
doc-index-file: $datadir/doc/$compiler/index.html
install-dirs user
docdir: $datadir/doc/$compiler/$pkgid
With the other options left at the default, this generates documentation in .cabal/share/doc/<ghc-version>/<package-name>, and the index in .cabal/share/doc/<ghc-version>/index.html.
There appears to be very little online - not even the haddocks for the cabal-install code. So your best bet may be to puzzle it out from the source. cabal unpack cabal-install, or view the cabal-install repo online. Look at SavedConfig in Distribution/Client/Config.hs. As an example, it imports GlobalFlags from Setup.hs; the individual flags, eg globalCacheDir, are associated with their config-file syntax (which is also the command-line syntax) in the globalCommand function below, remote-repo-cache in this case.
You should also ask dcoutts in the #haskell channel on irc.freenode.net, in case he has new docs available.
I am trying to update an old X11/Motif application to use modern objects and libraries. I used ldd to get a list of all the shared objects being used, but I am trying to figure out what functions in particular link to those libraries so I can remove the deprecated functions. Any ideas? Thanks
In particular (but not limited to), libXp.so.6
To see what functions are in libXp.so.6, try:
nm -D --defined-only /usr/lib/libXp.so.6
Now you can see that they all start with Xp, except for a few weird ones that probably aren't meant to be in the public API.
Your simplest approach is probably to just use grep to search for Xp, or a regex like Xp[A-Za-z]+, in the source code.
I'm working on a side project that involves sorting Japanese and Thai strings. When I was testing the sorting in client-side Javascript, I was able to use a.localeCompare(b, "languageCode") which worked. When I tried this same logic in Node, it did not work, because the Node INTL object is restricted to English as the default.
I want to customize my node build as described in the above link, and came across the ICU4C-data Node Module, which I understand contains a full set of ICU data. I've been playing around with different build flags, like the one specified by the (sparse) README: --icu-data-dir=node_modules/icu4c-data, to no avail - no matter which flags I set I cannot get the INTL Collator's compare function to give the expected results. Is there an obvious flag that I'm missing, or key assumption I have wrong?
Here are a few things important notes/resources:
The end goal is Thai & Japanese collation - if there's another approach using Node to implement this, I'm open to suggestions.
Collation must be done in Node
I'm going to be relying on Array.prototype.sort() - mainly looking for a comparator
Using Node 0.12, with ECMA support
My first time customizing a Node build (~1 month experience)
Install the full-icu package instead. It will give instructions on how to load the rest of the data.
Also note that future node versions should not require any configuration to pick up the new data, you can see #3460 if interested.
I need to fix the icu4c-data's readme to reflect this.