Which of these do I need...
and which should I uninstall? ...Jim Thompson
-- | James E.Thompson | mens | | Analog Innovations | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | San Tan Valley, AZ 85142 Skype: skypeanalog | | | Voice:(480)460-2350 Fax: Available upon request | Brass Rat | | E-mail Icon at
Leave them alone. The small libs are just pointers to the latest version that you've installed, in this case C++ 2012. Note the file sizes.
Various programs that you've installed also installed the C++ libraries that they need to run. If you uninstall the libs, the program(s) won't run. When the programs won't run, you'll post a question to S.E.D. asking why your program won't run. People will try to answer your question with suggestions that will only make things worse. Someone will surely suggest installing alternative C++ libraries. Computing will take a step backwards and civilization, as we know it, might collapse. We can't have that happening, so please leave the C++ libraries alone.
-- Jeff Liebermann jeffl@cruzio.com 150 Felker St #D http://www.LearnByDestroying.com Santa Cruz CA 95060 http://802.11junk.com Skype: JeffLiebermann AE6KS 831-336-2558
OK ;-) I just saw that pile and wondered what-the-hell! Personally I consider it poor programming style to need libraries. ...Jim Thompson
--
| James E.Thompson | mens |
| Analog Innovations | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| San Tan Valley, AZ 85142 Skype: skypeanalog | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |
I love to cook with wine. Sometimes I even put it in the food.
I beg to differ. The last thing I would want is to have every program on my machine have duplicate copies of all the standard libraries statically linked into the executable. The programs would all be huge.
Disclaimer: I are not a programmist.
-- Jeff Liebermann jeffl@cruzio.com 150 Felker St #D http://www.LearnByDestroying.com Santa Cruz CA 95060 http://802.11junk.com Skype: JeffLiebermann AE6KS 831-336-2558
How much huger, and would the additional bloat be offset by getting rid of all installers and uninstallers?
Op 10/19/2015 om 02:33 AM schreef Jeff Liebermann:
They won't. I link all my software statically to not depend on potentially incompatible / missing libraries. My typical GUI program is a few MB in size compared to needing several hundreds MBs for libraries. If I need external libraries I let them install in the same directory as the program's executable. There is just too much which can go wrong with depending on external libraries. Hard drives are so cheap nowadays that it's just not worth the hassle.
Ok, let's do the math. A "few MB in size" might be about 3MB. My Windoze XP machine has 13,000 EXE files. 3MBytes * 13,000 = 39GBytes of extra space needed. My working drive currently uses 300GB of diskspace, so that would be about a 10% increase. I'm not thrilled, but that might be tolerable. I'm not so sure the 3MBytes is a good number. If I scribbled a complex program, that used a wide assortment of libraries, I suspect it would be much larger.
Of course, why stop there? You could write everything in assembler and produce extremely small executables:
Reminder: I are not a programmist.
-- Jeff Liebermann jeffl@cruzio.com 150 Felker St #D http://www.LearnByDestroying.com Santa Cruz CA 95060 http://802.11junk.com Skype: JeffLiebermann AE6KS 831-336-2558
You probably don't have 13000 programs installed so the majority of those exe files must be libraries in some form.
3MB is typical of a complex GUI program. A command line program is usually less than 200kB. Using GCC helps a lot because MS Visual Studio can't compile C++ without needing redistributables.Den mandag den 19. oktober 2015 kl. 16.02.09 UTC+2 skrev N. Coesel:
Some things are easier when a program is just a single file, especially on windows where installing a missing library isn't just simple command.
But I understand the argument that static linking libraries is a bad idea, since bugs and security holes found in the libraries will not be fixed
-Lasse
On Sunday, October 18, 2015 at 4:20:28 PM UTC-7, Jim Thompson wrote: [about libraries required for a small program]
In a multi-user environment, using a shared library gives orders-of-magnitude speedup. For example, a 'print' function doesn't have to get swapped in for dozens of users, it's usually in cache already. It also enables processor changes (like Apple's 680x0 to PowerPC, and PowerPC to Intel) with minimal source code twiddling; you might be able to use the same source, just recompile and link with the 'new' library which comes with the OS. Or, you might do runtime interpretation of the old code, at near-native speed (because the 'inner loop' time usage is inside new-built libraries).
The UNIX trick of piping small programs would be inefficient if all the small executables contained local copies of library functions.
If you could turn off shared library links, the simplest little 'Hello World' program would get very large. I've done it- couple of orders of magnitude change in file size. If you can dynamically assign a shared library, every existing executable learns the new functionality (this requires some pointer-table trickery, but it's worthwhile).
Bottom line: libraries aren't going away. The upside: any MacOS program that needs a special library gets it bundled in a 'package' so the ensemble just looks to the user like one file.
Op 10/19/2015 om 07:53 PM schreef Lasse Langwadt Christensen:
A fixed library will have a new version number and the program will look for the old version so either way the bugs and/or security holes won't be plugged. New libraries often show different behaviour so you really don't want to replace a library with a new version anyway.
Besides that it is not really a problem. What user application is so sensitive that it can present a security thread? Especially if you are clever enough not to use your computer with administrator/root privileges.
10-4
I fully agree with that, I statically link in what I need due to the same reason. Also I don't want anyone playing around with any custom libs that I may make. The only think I may do is create some special DLL fills that may work with a set of EXE files belonging all to a single package or do something that can only be done in a DLL, like selecting specific LIBS to talk to some special interface etc..
Jamie
That depends very much on the system.
In GNU/Linux environments, apps are normally linked against the "canonical" version of the library name (e.g. "libc.so") which does not include the version number. The installed library has a version number in the name, but is "symlinked" to the canonical name by the library installation/management process. It's possible, and quite common, for updated version of a library to be installed during system maintenance operations; running programs continue to use the old version's memory image, but any newly-executed programs executed after the upgrade will access the newer version.
This is a primary mechanism for doing security upgrades.
A *major* upgrade in a library - one which changes the API enough to to make the new library incompatible with older applications - will usually result in the "canonical" version of the library name being changed, so that the two libraries can be installed "in parallel" and so that older apps can continue to run without interruption.
Any user application which can access a user's files is a potential security problem.
A fairly high percentage of security exploits in recent years have been ones in which somebody has figured out a way to carefully craft some data which, when processed by an application or library, results in some form of "code injection" into the running application/library memory image. This will then allow the exploit code to access all of the user's files, with the user's full privilege.
This may not allow the machine to be rooted... but it's entirely sufficient to allow a user's emails and contact list to be plundered, keystrokes to be logged, passwords and other access credentials to be found and misused, and the machine converted into a "botnet" slave which can spew spam and scan other hosts for possible vulnerabilities.
Most programmers today (they call themselves "coders", dude) don't know a thing about assembly, so it's not just that it takes more time. They don't know how. Most of them don't seem to understand things like data types, signed vs unsigned, two's complement, judging by the programmers I've met.
But you don't really need assembly. C can be made almost as efficient, and the compiler can optimize for speed better. It's just that they don't know how to do that either because programmers are not taught well enough IMO.
And hard drive space is only as cheap as it is because drives are not as reliable as we'd like. High-reliability drives are much smaller for the same price.
Those are Wannabees!
Jamie
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.