# How to verify the version of Adobe Flash Player plugin installed in Linux/Firefox



## lotuseclat79

The most accepted way is to bring up a blank tab and in the address location bar type: aboutlugins
which reveals: Shockwave Flash 10.1 r85
and only gives you part, but not the whole version of the Adobe Flash Player.

Here's how to do it like a Linux pro:

1) $ cd ~/.mozilla/plugins
2) $ strings libflashplayer.so | grep '10.1.85.3'

The output you should be seeing after the strings command is the following for the latest security fix:
FlashPlayer_10_1_85_3_FlashPlayer
LNX 10,1,85,3

Note1: The character '.' in a grep command matches any character.
Note2: The Firefox profile for Linux resides in ~/.mozilla/...
Note3: If you do not see the above version, 10.1.85.3, then you need to get the latest update here.

-- Tom


----------



## lotuseclat79

A more convenient way is to create an alias in your .bash_aliases file in your user accounts /home/<user account> directory with the following alias:
alias ckflsh="pushd ~/.mozilla/plugins 2>&1 >/dev/null; strings libflashplayer.so | egrep 'FlashPlayer_|_FlashPlayer';popd 2>&1 >/dev/null"

Then after the edit, execute: the command: 
. .bashrc 
(assuming your have the following commands in your .bashrc file):
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
where the file .bash_aliases contains all of your aliases.

Finally, to check your Flash version, simply execute the alias on the command line:
$ ckflsh

-- Tom


----------



## lotuseclat79

Here is an example variant of the alias for a Firefox derivative, e.g. Icecat which uses Gnuzilla - note it only needs a minor directory change:

alias ckiflsh='pushd ~/.gnuzilla/plugins 2>&1 >/dev/null; strings libflashplayer.so | egrep '\''FlashPlayer_|_FlashPlayer'\'';popd 2>&1 >/dev/null'

Further variants are possible with different alias names depending on where Adobe Flash player is installed, i.e. in a different directory such as a globally available instance of libflashplaye.so to all users on a system rather than in the user's profile (home directory).

If previous variants of the alias did not work for you, then my advice is to chase down where your Adobe Flash player is installed and substitute that directory (which locates the file: libflashplayer.so) into the alias as the argument to the pushd command in the alias - then it should work.

-- Tom


----------



## tomdkat

Thanks for the tips. I use a different method to get the Flash version. When viewing a page with a Flash object on it, I right-click on the object and click "About Adobe Flash Player". Then a page on the Adobe site is displayed with the Flash version shown. Or, I'll visit a site like this one which will display the version info.

Peace...


----------



## lotuseclat79

Hi Tom,

The method you use requires an Internet transaction. This is the same sort of thing that I rebelled from when i first started to do research on the Web in the early 1990s with the NetScape NCSA browser - i.e. home pages were typically links to other web sites. I have since either used a local file or a blank page. My assessment of that is and remains that it is an unnecessary transaction to use remote web pages for a home page - same to find out a version of software installed on your local system or plugged into your browser. Luckily, also, accessing "aboutcolonplugins" in Firefox will also tell you the version of Adobe Flash installed as a plugin. However, Adobe Flash can be installed in several different directory locations on a Linux system as well, which I have not yet addressed in this thread - time to get out my notes and post that information in this thread - now, where did my notebook walk off to this time?

-- Tom


----------



## tomdkat

You're very correct. However, Flash objects are generally or typically viewed on the web, which requires an "Internet transaction", to use your words.

If your browser home page is a blank page, obviously finding a site to check the Flash player version info can be a pain. If your browser home page is set to a "live" site, that page might already have a Flash object embedded in it and the right-click method is easy and convenient.

I guess my main point is I disagree with having to use convoluted commands in a shell to determine the version of Flash player that is installed as doing it as a "Linux Pro".  lol I find "having" to open a shell to enter some commands to determine the Flash player version just as unnecessary as you think of using a website to get the same information.

On a side note, what I find interesting is both Chrome and Opera use the location of Firefox plugins to load those same plugins. 

Peace...


----------



## lotuseclat79

Hi Tom,

But, as I did say, in your browser select aboutcolonplugins in the address location window to find out what version is installed in Firefox. No Terminal window shell command required. In aboutcolonplugins replace colon with ':'.

On another note, it looks like the .deb version of Adobe Flash Player installed may be linked into the following directories:
/usr/lib/adobe-flashplugin/libflashplayer.so (Installation directory)
/usr/lib/xulrunner-addons/plugins/
/usr/lib/iceape/plugins/ (Firefox variant)
/usr/lib/iceweasel/plugins/ (Firefox varian)
/usr/lib/midbrowser/plugins/
/usr/lib/xulrunner/plugins/
/usr/lib/mozilla/plugins/
/usr/lib/firefox/plugins/
and /usr/lib/icecat/plugins (Firefox variant not included in Adobe Flash .deb)

-- Tom


----------



## tomdkat

Yep and as you also indicate, the complete version information isn't provided. Additionally, if I use the Adobe Flash player version page, I can immediately know if I have the latest and greatest version installed or not.

Knowing I have Flash Player 10.0 r45 is fine but knowing I have version 10,0,45,2 installed AND that's not the newest version is better. With this additional information, I can decide if I want or need to upgrade the installed Flash player.

In my particular case, upgrading the Adobe player isn't easy since I'm running 64-bit Linux and I believe Adobe has stopped updating the 64-bit native Linux Flash player.

Lastly, I don't install the Flash player in any system-level directory but in my home directory only.

Peace...


----------



## lotuseclat79

Hi Tom,

You should check Adobe's Flash Player Download web page for more information on the 64-bit Linux version.

A new wrinkle I just found is that the size and date information varies on version 10.1.102.64 (i.e. the latest fix) between the tar.gz version and the .deb version (downloadable) from Adobe's website - lax QA IMHO.

Both libflashplayer.so files indicate version 10.1.102.64, when I check them with my alias command however,
the tar.gz version indicates a larger size and earlier date:
-rw-rw-r-- flplbldr/flplbldr 11952144 2010-10-22 01:05 libflashplayer.so
and the .deb version indicates a smaller size and a later date:
-rwxr-xr-x 1 ubuntu ubuntu 11935548 2010-10-26 12:03 libflashplayer.so

I am going with the later dated vesion.

-- Tom


----------



## tomdkat

Maybe when generating the deb version, they built with "Ubuntu" style compile flags or something?

Peace...


----------



## lotuseclat79

Hi Tom,

Whether they build with different compile flags or not, the issue is that on all Linux systems, the file should be the same - it should not matter whether the distribution container packaging is a .deb or a .tar.gz - the file within the distribution container package should be the same, respectively for 32-bit and 64-bit instances of the same version, i.e. no date or size differences!

-- Tom


----------



## tomdkat

lotuseclat79 said:


> Whether they build with different compile flags or not, the issue is that on all Linux systems, the file should be the same - it should not matter whether the distribution container packaging is a .deb or a .tar.gz - the file within the distribution container package should be the same, respectively for 32-bit and 64-bit instances of the same version, i.e. no date or size differences!


How can you say this? If the same source code is compiled with different compile options and at different dates/times, of course the resulting object files can have different sizes. If the deb version was built with "Ubuntu" style or standard compile flags and the version distributed via standard tarball was built with different compile flags, it's reasonable that the resulting library would have different sizes.

The question is how was the library in the deb version built vs the one in the tarball. Perhaps different optimization settings were used for the deb, per Ubuntu source compiling conventions, that were not used for the tarball.

Your comment above works if you assume they build the library for Linux once (for 32-bit platforms since they don't build for 64-bit anymore) and then package the resulting files in various manners for distribution. If they build differently depending on how the result will be packaged, the file size differences you're noticing might not be anything to be concerned with and could be normal.

Does Adobe publish how they build the Flash player for Linux?

Peace...


----------



## lotuseclat79

Hi Tom,

The question is not "how was the library in the deb version built vs the one in the tarball". There is but one set of flags to build the executable, and from there it is packaged into a .deb, or a tar ball and compressed via different compression routines for distribution, e.g. bz2, xz, gz or put into the rpm form of distribution.

I do not know if Adobe publishes how they build Flash Player for Linux. Consistency in all distribution instances of an executable is a desirable characteristic, e.g. they should all have the same md5sum, or signature. In the case that I pointed out, they do not. At the very least, Adobe should publish the signature information to make sure when a user reports a problem - both the user and Adobe are on the same page with regard to the instance of the executable that is the object of concern. Again, in the case I pointed out there is divergence in that regard. QA should be in charge of the release, and this case is suspect IMHO.

-- Tom


----------



## tomdkat

lotuseclat79 said:


> The question is not "how was the library in the deb version built vs the one in the tarball". There is but one set of flags to build the executable, and from there it is packaged into a .deb, or a tar ball and compressed via different compression routines for distribution, e.g. bz2, xz, gz or put into the rpm form of distribution.


And you know this how? Or are you speculating? Is there something in the Flash player distribution that will tell you the compile flags used to build it?



> I do not know if Adobe publishes how they build Flash Player for Linux. Consistency in all distribution instances of an executable is a desirable characteristic, e.g. they should all have the same md5sum, or signature. In the case that I pointed out, they do not. At the very least, Adobe should publish the signature information to make sure when a user reports a problem - both the user and Adobe are on the same page with regard to the instance of the executable that is the object of concern. Again, in the case I pointed out there is divergence in that regard. QA should be in charge of the release, and this case is suspect IMHO.


I agree. My point is, until you find out if there are differences in how the library was built, you could be concerned about nothing.

On a side note, I'm glad you started this thread because it caused me to visit the Adobe Flash player download page. Much to my surprise, I learned they have released a preview release of Flash Player 10.1, which is 64-bit naive for Linux and includes enhanced IE9 support. I'll have to give it a whirl. 

Peace...


----------



## lotuseclat79

Hi Tom,

There are only two targets to build the application for: 32-bit and 64-bit. Then comes the different distribution packaging: tar.gz, .deb, and .rpm, etc. I have never built an executable for a targeted architecture differently. A different target architecture than the x-86, or x-64, like Sparc, Mips, ARM, etc. would probably be built with different compile flags, but not for one target architecture platform: Linux/x-86. Out of necessity, the x-64 target would have one or more different valued flags. I started my software engineering career as a compiler engineer.

I do not think that Adobe Flash Player is open source, so it would have to be for them to publish the compile flags.

-- Tom


----------



## tomdkat

lotuseclat79 said:


> There are only two targets to build the application for: 32-bit and 64-bit. Then comes the different distribution packaging: tar.gz, .deb, and .rpm, etc. I have never built an executable for a targeted architecture differently. A different target architecture than the x-86, or x-64, like Sparc, Mips, ARM, etc. would probably be built with different compile flags, but not for one target architecture platform: Linux/x-86. Out of necessity, the x-64 target would have one or more different valued flags.


Understood. However, since we don't know *how* Adobe is choosing to build the Flash player for Linux, we don't know if the size difference you've noticed is anything worth worrying about. I'm saying a different set of compile flags is one *possibility*. I'm sure there are others. You have also pointed out the deb packaged version has a different date stamp than the tarball. Perhaps the two were built on two different systems with two different compiler versions? Perhaps there was a change in how the player was built in the handful of days between the two files were generated?

Until you know *how* the player was built, it's premature to think something is wrong, don't you think?



> I do not think that Adobe Flash Player is open source, so it would have to be for them to publish the compile flags


In addition to that, it would be great if they published more about the build environment, in general.

Peace...


----------



## lotuseclat79

Hi Tom,

It is never premature to think that something is suspect based on the evidence - they should be consistently the same executable, and they are not, i.e. they are awry.

Firefox does have the way it was built in the webpage, about:buildconfig - which is the kind of information you are talking about wrt Adobe's Flash Player. Even if there were a change in how it was build between the two versions, that does not account for the inconsistency in the distribution between the two - which is a requirement for robust build and distribution.

-- Tom


----------



## tomdkat

lotuseclat79 said:


> It is never premature to think that something is suspect based on the evidence - they should be consistently the same executable, and they are not, i.e. they are awry.


You're coming to conclusions based on your perspective of things. I think you're in a great position to ask questions but to go farther than that is definitely premature, simply because you don't have any other data other than a difference in file size and date stamp. If anything, the main questions I think can be asked are:

Why do these files have different sizes and date stamps?
Is this correct?
Neither question makes any judgment or draws any conclusion. A difference between the files does not mean anything is awry, by virtue of the differences being present.



> Firefox does have the way it was built in the webpage, about:buildconfig - which is the kind of information you are talking about wrt Adobe's Flash Player. Even if there were a change in how it was build between the two versions, that does not account for the inconsistency in the distribution between the two - which is a requirement for robust build and distribution.


Thanks for mentioning Firefox. It would be interesting to see the various ways in which Firefox is built, since the Linux distro maintainer might build Firefox for said distro, vs simply including the binary made available from the Firefox distribution site(s). At least we can compare the files built by whomever built the tarball released for distribution from Mozilla with the files built by the distribution maintainer.

If there was a change in how the build was done between the dates reported by the date stamps of the files, that mostly certainly would or could account for the inconsistency. The question of *why* the inconsistency occurred would remain unanswered. They question of "why were there different builds?" and related questions would remain.

If variations of file sizes and build dates are part of Adobe's internal processes, that's fine and could further account for what you noticed above. You might disagree with Adobe's approach, and that's fine, but we would hopefully have far more information for consideration if we reached that point.

Getting back to your Firefox example, since Ubuntu builds the 64-bit version Firefox for inclusion with the 64-bit distro, I downloaded Swiftfox, which is another 64-bit Firefox version that's available. Mozilla still doesn't distribute 64-bit versions of Firefox and that might change with Firefox 4.

In any event, I found Ubuntu uses much different compile flags than the Swiftfox maintainer.

Ubuntu:


Code:


compile options:
gcc 	gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) 	-Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -Wno-long-long -pedantic -g -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions

configure options:
--build=x86_64-linux-gnu --prefix=/usr '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' --sysconfdir=/etc --localstatedir=/var '--libexecdir=/usr/lib/firefox' --disable-maintainer-mode --disable-dependency-tracking --disable-silent-rules --srcdir=. --enable-optimize --enable-ipc --enable-tests --enable-mochitest --disable-system-cairo --disable-system-sqlite --without-system-nspr --without-system-nss --enable-extensions=default --enable-crashreporter --disable-debug --with-user-appdir=.mozilla --without-system-jpeg --without-system-zlib --enable-system-myspell --disable-composer --disable-elf-dynstr-gc --disable-gtktest --disable-install-strip --disable-installer --disable-ldap --disable-mailnews --disable-profilesharing --disable-strip --disable-strip-libs --disable-tests --disable-mochitest --disable-updater --disable-xprint --enable-application=browser --enable-canvas --enable-default-toolkit=cairo-gtk2 --enable-gnomevfs --enable-pango --enable-postscript --enable-svg --enable-mathml --enable-xft --enable-xinerama --enable-safe-browsing --enable-single-profile --with-distribution-id=com.ubuntu --enable-startup-notification --enable-official-branding

Swiftfox:


Code:


compile options:
gcc-4.1  	gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)  	-O3 -march=athlon64 -pipe -fomit-frame-pointer -D_FORTIFY_SOURCE=2 -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -Wno-long-long -pedantic -O3 -march=athlon64 -pipe -fomit-frame-pointer -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -O3 -march=athlon64 -freorder-blocks -fno-reorder-functions -msse2 -mmmx -m3dnow -mfpmath=sse -D_FORTIFY_SOURCE=2

configure options:
--with-pthreads --enable-application=browser --enable-default-toolkit=cairo-gtk2 --with-distribution-id=Swiftfox --disable-freetype2 --enable-single-profile --enable-extensions=default --disable-installer --disable-tests '--enable-optimize=-O3 -march=athlon64 -freorder-blocks -fno-reorder-functions -msse2 -mmmx -m3dnow -mfpmath=sse -D_FORTIFY_SOURCE=2' --disable-profilesharing --disable-debug --enable-xft --enable-crypto --enable-svg --enable-canvas --enable-update-packaging --enable-xinerama --enable-libxul --enable-webservices --disable-necko-wifi

Unfortunately, the Swiftfox release is at 3.6.10 while Ubuntu has distributed 3.6.12 but it's interesting to see the difference in compile and configure options used by both, since both are targeting the same CPU architecture.

So, my question to you is: why NOT find out what could have caused the difference in file sizes and generated file dates _before_ coming to any conclusions? Have you asked Adobe about the file size difference you've found?

Peace...


----------



## lotuseclat79

Hi Tom,

Your assumptions aside with due respect to your POV, they simply goofed. I say this not lightly as I expect their QA process may be flawed to not prevent this kind of oversight.

I do not intend to bring it to Adobe's attention. The observation I made is known as an inconsistency which is not congruent with current practice of QC to prevent such occurrences, otherwise, how will Adobe know which is which unless they ask the user more than which version has a problem, i.e. what method did you use to install Flash Player.

No matter which method of installation is used, the result should be the same executable - and with this kind of inconsistency - no matter that it may even be inconsequential, the potential for further problems exist.

-- Tom


----------



## tomdkat

Wow, I'm literally floored. You have *no* idea how Adobe's processes work, are *not* going to find out if this was intentional or an oversight, and then criticize their QA dept, again *not* knowing how it operates or functions. Unreal.

Well, it's certainly within your purview to take this position but I must honestly admit I'm rather surprised by your position.

As for my assumptions, I'm not assuming anything. I am fully aware of the fact I have no idea about what actually happened on their end and if it was an issue for me (if I had made the same discovery you did), at the very least I would try to find out what happened before coming to any conclusions. What I pose above are *possible* explanations. Possibilities, that's it. The only thing I know is what you've found: there are differences (not necessarily discrepancies) in the file size and date stamp of the same version of the Flash player shared library file for Linux they are distributing. Other than that, the only "answer" I have for the relevant questions is "I don't know".

Good luck with your project. 

Peace...


----------



## lotuseclat79

Hi Tom,

I am long-in-the-tooth, so to speak, in terms of system software engineering - and I would never allow such a discrepancy such as you are so foregiving - i.e. however Adobe is running its QA or however its internal processes work to distribute software - there is nonetheless a discrepancy that should never occur.

Good luck with your approach!

-- Tom


----------



## tomdkat

lotuseclat79 said:


> I am long-in-the-tooth, so to speak, in terms of system software engineering - and I would never allow such a discrepancy such as you are so foregiving - i.e. however Adobe is running its QA or however its internal processes work to distribute software - there is nonetheless a discrepancy that should never occur.


The thing is, you don't even know if there is a discrepancy! lol

Forgiving? Nope, just acknowledging I *don't know* what happened internally at Adobe. If it were established fact that Adobe screwed up and I were to defend the screw up or come up with a way to justify it, *that* would be forgiving.

To call it a screwup *without knowing anything* about their internal processes, how does that work? What would you call that?

I guess the difference between our perspectives is I need evidence that something is wrong and you simply trust your gut. 

Thanks for the wish of luck and I must admit my approach can be frustrating sometimes since it can really be challenging to actually get the proof of there something being wrong or getting others to accept the proof I might present to them. 

Peace...


----------



## lotuseclat79

tomdkat said:


> The thing is, you don't even know if there is a discrepancy! lol
> 
> To call it a screwup *without knowing anything* about their internal processes, how does that work? What would you call that?
> 
> Peace...


Hard core experience with similar problems in the past allows me to, as you say, thrust my gut on such issues!

-- Tom


----------

