Usb Library Version 03.02.07
Mirthe Luria
I work for a design system team, and we update our library according to a certain cadence.
The issue is that sometimes, designers working for the product want to stick to a specific version of the library and if they start a new file, for example, they cannot choose a previous version.
There's a gigantic source package I am considering downloading which I'm sure will do proper checks and lists a mininum library version, but I'd rather save myself a potential hassle by checking first if it will work.
Unfortunately, the man page does not provide a version number. ldd still comes in handy, since any working, dynamically linked executable on the system (e.g., almost everything in /usr/bin) will link to the C library.
A system isn't actually limited to one C library. Most, though, primarily use only one, which will also be the one the default compiler uses. And since you're downloading source code to compile, that's the one you're concerned with.
You now have the path to the C library. You could look this up in your package manager to find the package (e.g., dpkg -S /lib/x86_64-linux-gnu/libc.so.6 or rpm -q -f /lib/x86_64-linux-gnu/libc.so.6).
Note how the GLIBC_2.18 symbol has the most recent version number among the symbols listed, and the library version is indeed 2.18. It's eglibc, though (it aims to be binary-compatible with glibc 2.18, so it uses the same symbol versions).
NOTE: The Debian package utility dpkg-shlibdeps uses objdump under the hood, along with stored symbol information in Debian library packages to determine the minimum versions of dependencies required by binary Debian packages at build time. Basically, it looks at the symbols exported by the binary Debian package, and then finds the minimum versions of the libraries that contain those symbols.
GNU libc (what most Linux distributions use in one form or the other) goes to great lengths to keep strict backwards compatibility. So you should run into trouble only if you try to run a too-new binary on an old version (or a "enterprise" distribution, they normally freeze versions, particularly foundation ones like the C library, backporting fixes while keeping rigurous binary compatibility). I believe you are much more liable to run into problems with other libraries (C++ had a few API/ABI changes in recent memory, some other libraries just don't care for backward compatibility).
The core shared library for GNU libc, libc.so.6 (on Linux; Hurd has a different SONAME), has the unusual property (for shared libraries) that you can invoke it as an executable. If you do, it prints out the sort of thing GNU utilities usually print when run with --version, like this:
When Roon Radio decides to choose a track, is there a way to tell it to always choose the local library version over streaming (Qobuz for example)? Or for example, only choose tracks from my local library for the next track to play?
Unfortunately the managed library system is not a fully fledged version control system so you are unable to revert to an earlier version which is one of the reasons I don't use managed libraries, as they've also been squirrelled away locally too so you can't have local version control either....
I hope they do something to alleviate this issue soon. My preference would be to be able to locally version the source managed library files using GIT so maybe not having your own personal libraries squirrelled away would be a good option to alleviate the issue. It makes sense to do this for the Autodesk curated standard libraries, but to bury your user generated files where they are a pain to backup/version control is a big fail IMHO.
We're currently using git for library handling, but it's a little clunky (requires another tool, it's not completely automatic, it's hard to merge libraries etc). I have high hopes for where this can go in the future, because I think the idea is very good
Unfortunately I'm forced to use managed libraries since I'm using the fusion 360 integration with my mech team and that requires managed libraries to store the CAD files. I guess I'm just stuck with this half-baked library management system until Autodesk figures out how to make it proper version control.
Great to hear that you're working on the better version control support for managed libraries! The shared managed library in a collabortive environment will is a feature with great potential. Unfortunately, it's not there quite yet. I have a few requests (concepts) that I would really like to see in the future (basically various git-concepts) that I think would improve collaborative possibilites a lot:
- Diff functionality between versions. Basically a way to see what's different between two library versions (which components have changed and how). This is already implemented for merge conflicts (if your changes on a component are different from recently pushed changes). It works OK currently, but it would be very good to be able to open the two components side by side and compare them directly.
- Approval/review functionality. Similar to pull-requests in software. Someone else needs to approve what the changes you have made to the library before you can actually push your changes to the library.
While I patiently wait for Autodesk to make progress on managed library version control, what I have been doing is finding where the managed libraries are locally stored and copying them periodically.
By opening one of the managed libraries in EAGLE and clicking Save As, I was able to find that they were stored in Windows under my user's AppData directory (%HOMEPATH%\AppData\Roaming\Eagle\lbr). They are all in hundreds of adsk.eagle_library_XX folder names. Fortunately, the libraries I use all had a prefix, so I was able to use the File Explorer search to easily narrow down on all libraries that belonged to me with a search parameter like this: "-XXX*lbr". Then I select everything in this directory and copy it to a backup folder.
I can agree with you, and the project already states all the top-level library in platform.ini. However, given that the libraries are usually specified as library-name@^version, we are not sure to have the exact same version.
These interfaces provide the same information as the SQLITE_VERSION,SQLITE_VERSION_NUMBER, and SQLITE_SOURCE_ID C preprocessor macrosbut are associated with the library instead of the header file. Cautiousprogrammers might include assert() statements in their application toverify that values returned by these interfaces match the macros inthe header, and thus ensure that the application iscompiled with matching library and header files.
PLC libraries contain a global constant of the type ST_LibVersion, where you can find information about the library version. This constant can be read during runtime and compared with a required library version, using the function F_CmpLibVersion (see Tc2_System library).
As soon as an archive (e.g. PLC archive or TwinCAT archive) is created or the TwinCAT configuration is activated on the target system, however, the library versions should be fixed. The easiest way to do this is to use the 'Set to Effective Version' command in the context menu of the reference node.
We have settled on a best-practice of always referencing the production-library in all projects (even if the projects themselves are in development or test). We came to this after realizing that a referenced library is essentially copied into a project when the project is deployed. There is no need to reference a library only from the same environment.
- in a c# class (included in a library) I remove some methods that are marked as deprecated in previous versions, so the project must include this (latest) version of the library only when they have purged the deprecated calls.
- in a c# class i wrote new public methods that give new funcionalities to the users (users=project that need to use library), so it is not necessary to redeploy all projects (spending many time) only to update the library version (to the latest one), but only the projects that want to use these new methods.
The library 'version' gets carried with the solution project file regadless of the environment and as I think we all know the version number is not really a version number at all but rather the sequence number of the library deployment into any given environment. So there is no consistency of version number to code across environments.
Another complication is that of the library cache. In my experience even if you are connected to the respository you wish to work against and select to use a particular version in your project (add this version to your project), if that version exists in your library cahce it will be loaded from local cache rather than from the respository. This then adds version control of your local library cache into the mix. For this reason it is wise to clear the cache periodically and for me essential whenever deploying to production environments.
What we could really do with is real versioning for libraries so that no matter what environment we're using the version of the library code is known rather than the sequence number which only serves to confuse which version is actually being used. I don't think that this should be too hard for OT to achieve.
a71949beef