|
Softpanorama
(slightly skeptical)
Open Source Software Educational Society |
May the
source be with you,
but remember the KISS principle ;-)
|
Solaris Specific Problems with OSS Linking and Compilation
See also GCC on Solaris. A very good article
by Rich Teer
Build-Install OpenSolaris at OpenSolaris.org might be
helpful too:
This is the first of two articles in which we describe
how to acquire and build the source code for OpenSolaris.
The first article provides all the necessary background
information (terminology, where to get the tools, and so on)
and describes a basic compilation and installation, and the
second article will describe a more complicated compilation
and installation.
These articles describe how to build and install
OpenSolaris; they are not intended to be an "OpenSolaris
developers' guide", so information beyond that which is
required for building and installing OpenSolaris is not
included. This should not be seen as a problem, however,
because (as with most other large-scale open source
projects) the number of active OpenSolaris developers who
will need this knowledge is likely to be small compared to
the number of people who will want to build it for their own
edification.
These articles assume at least a passing familiarity with
building major software projects and some C programming. It
is unlikely that someone who is struggling to compile "Hello
World" would be trying to compile OpenSolaris! However, we
will otherwise assume no knowledge of building Solaris, and
describe all the necessary steps.
Notes:
- Those pages are written by people for whom English is not a
native language. Some amount of grammar and spelling errors
should be expected.
- This is a Spartan WHYFF (We Help You For Free) site. It
cannot replace the best teachers and
the
best books.
- The site contain some obsolete pages as it develops like a
living tree... Some links on older pages
are broken. Please
try to use Google, Open directory, etc. to find a replacement link
(see
HOWTO search the WEB for details).
We would appreciate if you can
mail us a correct link.
|
|
What could possibly be so difficult
about porting the Flash Player to Linux?
I'm glad you asked.
The executive summary of what follows
would probably be: ensuring that a
single plugin binary functions on the
widest diversity of Linux/x86
distributions within reason. Read on for
the details.
First, we take the existing Flash
Player 7 Linux code along with the
current revision of the main Player
codebase, modify the Linux-specific
stuff as needed, and get the plugin to
compile in the first place. Then we
upgrade the Linux-specific parts to take
advantage of all the latest v8 and v9
features. Which APIs to use? That has
already been covered in copious detail
throughout previous posts.
While we have the plugin limping
along on our development machines, there
comes a point where we need to hand off
builds to our QA team for testing. This
is when we notice that the plugin works
great on our dev boxes, but hardly or
not at all on any other distributions.
Generally, the problem is libraries,
libraries, libraries. For example, the
player dynamically opens libasound.so to
dig out the ALSA audio functions. I
recently learned that the 'libasound.so'
symlink is only available on systems
with the right devel packages installed.
The proper file to open is
'libasound.so.2'. Hopefully. Repeat for
the rest of the dynamic library loads.
Things get more painful when the
plugin refuses to load. The first line
of debugging is the 'ldd' utility to see
if the plugin is finding all of the
libraries it wants on its new host
system. A major problem has been that
the plugin wants to find libstdc++.so.6.
Certain older Linux systems that we are
trying to support only have libstdc++.so.5.
This is not something we can plausibly
dynamically load at runtime as in the
case of libasound.so.2. This is why
I wanted to know how to statically link
libstdc++.so.6 with the main
binary-- larger distro range.
Many thanks to participants on the
Automake mailing list as well as my
contacts at Red Hat, we actually figured
out how to do this (it has to do with
the way to toolchain is built vs.
specific project built options).
Next problem: The plugin does not
load on stock Fedora Core 5 or 6
systems. All the libraries are present
and resolving this time. So what's going
on? These systems come "hardened" from
the start and they don't like binaries
that contain something called text
relocations ("textrels"). These textrels
are caused by 2 things in this case:
- statically linking
libstdc++.so.6
- manual assembly language
optimizations
For number 1, we embarked on a new
adventure to build a super-special
custom toolchain that builds
libstdc++.so.6 just right so that it can
be static linked with the plugin without
those nagging textrels. The ASM
optimization bits are giving us some
problems but
Tinic thinks he has a way to make
those functions play ball in order to
create a fast binary. So now the plugin
works on hardened Linux or SELinux or
whatever the right buzzword is; it works
with a Linux distro that uses the
security feature of randomizing a
program's base address.
I hope I've answered your question.
sunfreeware.com Comments
on gcc To use the gcc package from sunfreeware.com you
MUST install all of the SUNW deveoper packages that come on Sun's
Solaris CDs.
The software used to create gcc 3.4.2 (the steps are very similar for earlier
versions of gcc) was all from packages on sunfreeware.com. These include the
gcc-3.3.2, bison-1.875d, flex-2.5.31, texinfo-4.2, autoconf-2.59, make-3.80, and
automake-1.9 packages. It may also be important to install the libiconv-1.8
package to use some of the languages in gcc 3.4.2. See also a comment below
about the libgcc package.
- I downloaded the gcc-3.4.2.tar.gz source from the GNU site.
- I put the source in a directory with plenty of disk space.
- I then ran
gunzip gcc-3.4.2.tar.gz
tar xvf gcc-3.4.2.tar
(this creates a directory gcc-3.4.2)
cd gcc-3.4.2
mkdir objdir
cd objdir
../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld
--disable-nls
(except in the case of Solaris 2.5 on SPARC where I used
../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls --disable-libgcj --enable-languages=c,c++,objc
and left out the other language options - like the gnat ada.)
(I choose to use the as and ld that come with Solaris and are usually
in the /usr/ccs/bin directory. These files are only there if the
SUNW developer packages from the Solaris have been installed. I
have noticed problems with the NLS support and so I disable that. The
default installation directory is /usr/local.)
make bootstrap
make install
(this puts a lot of files in /usr/local subdirectories) and the gcc
and other executables in /usr/local/bin.
- I put /usr/local/bin and /usr/ccs/bin in my PATH environment.
There are differences between this version of gcc and previous 2.95.x versions
on Solaris systems. For details, go to
http://gcc.gnu.org/gcc-3.4/
In particular, gcc-3.4.2 offers support for the creation of 64-bit
executables when the source code permits it. Programs like top, lsof, ipfilter,
and others support, and may need, such compiles to work properly when running
the 64-bit versions of Solaris 7, 8, and 9 on SPARC platforms. In some cases,
simply using the -m64 flag for gcc during compiles (which may require either
editing the Makefiles to add -m64 to CFLAGS or just doing gcc -m64 on command
lines) works.
When you compile something with any of these compilers, the executable may
end up depending on one or more of the libraries in /usr/local/lib such as
libgcc_s.so. An end user may need these libraries, but not want the entire gcc
file set. I have provided a package called libgcc (right now this is for
gcc-3.3.x but a version for 3.4.x is being created) for each level of Solaris.
This contains all the files from /usr/local/lib generated by a gcc package
installation. An end user can install this or a subset. You can determine if one
of these libraries is needed by running ldd on an executable to see the library
dependencies.
I am happy to hear about better ways to create gcc or problems that may be
specific to my packages. Detailed problems with gcc can be asked in the
gnu.gcc.help newsgroup or related places.
Sun Studio 11 Sun Studio 11 software removes the price barrier and is available for Free!
Sun Studio 11 software is the latest
release of record-setting, optimizing compilers and tools for the C, C++
and Fortran developer. This release delivers the highest optimizations
and the best performance in the development of scalable 32-bit and
64-bit applications on Sun's newest hardware platforms including the
latest multi-core UltraSPARC, x64 and x86 platforms. And Sun Studio 11
software now removes the price barrier and is available for Free!
Sun Studio 11 software compilers allow developers to leverage the
latest in parallel programming and maximize throughput on multi-core
systems. In addition, even single-threaded applications gain as the
compilers can identify opportunities to parallelize execution and
automatically, without source-code changes, produce back-end code to
take advantage of this.
Build-Install OpenSolaris at OpenSolaris.org
by Rich Teer
This is the first of two articles in which we describe
how to acquire and build the source code for OpenSolaris.
The first article provides all the necessary background
information (terminology, where to get the tools, and so on)
and describes a basic compilation and installation, and the
second article will describe a more complicated compilation
and installation.
These articles describe how to build and install
OpenSolaris; they are not intended to be an "OpenSolaris
developers' guide", so information beyond that which is
required for building and installing OpenSolaris is not
included. This should not be seen as a problem, however,
because (as with most other large-scale open source
projects) the number of active OpenSolaris developers who
will need this knowledge is likely to be small compared to
the number of people who will want to build it for their own
edification.
These articles assume at least a passing familiarity with
building major software projects and some C programming. It
is unlikely that someone who is struggling to compile "Hello
World" would be trying to compile OpenSolaris! However, we
will otherwise assume no knowledge of building Solaris, and
describe all the necessary steps.
[Nov 1, 1999]
Porting
Open Source Software to SCO Dr. Ronald Joe Record Open Source Program
Architect
Much of the most useful and popular software
today is published and distributed in source form. The Apache web
server, KDE, the Mtools DOS utilities and the GNU C compiler are a few
examples of what is commonly referred to as Open Source software. This
article attempts to provide some insight, tips, techniques and
methodology for building Open Source software on and for
SCO OpenServer 5,
UnixWare 7 and in general.
The targets in CGC are configured by default with reasonable
guesses about the compile and link options that are required to compile the
code. However, the actual options required depend on your system configuration.
For instance, your default cc compiler may not have been configured
to automatically find the X11 include files. You might, therefore, get an error
message the Xlib.h cannot be found. You should find out where on
your system Xlib.h is installed, use the `T edit-target' command to
add a compile option of the form -Lpath_name where
path_name is the full path of the directory containing the file. `T
edit-Target' is on the shift-middle-button menu.
Recall that X started in about 1984 to be the platform independent
interface thingy. It is supposed to work everywhere - yes even on your
PC/AT, and even on your Mac (<- on the Mac X even works with DECnet transport
protocol [though tcp/ip is much more common]!). In raw source code form it is
available for free.
Here are some interesting excerpts from X Window System C Library and
Protocol Reference by Robert W. Scheifler, James Gettys, Ron Newman, Al
Mento, and Al Wojtas (© 1988 MIT and DEC ISBN 1-55558-012-2):
The X Window System(tm), or X, is a network-transparent window system...that
was designed at MIT.
...
It runs under ... several operating sytems.
...
Xlib is a C subroutine library that applications programs (clients) use to
interface with the window system by means of a stream connection.
Please note that while much X documentation refers to "X toolkits" (e.g.
Xt, Xm, Xmu, etc.) such toolkits are typically front
ends to C subroutine libraries. Hence those "toolkits" are typically
called from some other compiled language (which is usually C or C++). Perl/Tk
(and Tcl/Tk for that matter) is (are) a bit more than mere "toolkits"
in that they allow access to a good deal of Xlib functionality via the other
languages (Perl and Tcl respectively). [BTW there also is a Lisp version of Xlib
that you need not concern yourself with in an attempt to port Perl/Tk.]
Take a look at "Getting
X" from the folks who write and maintain it.
They (the X consortium) also have a page on Writing
Portable X Code which is a must read document. You should probably
check out the Xlib man
pages too.
Perl/Tk can be built on Unix platforms under X11
R5, R6,
R6.1, and R6.3.
I do not know if it has been built with prior releases. The X Consortium plans
on calls the latest release of X "Broadway"
or X11R6.3. See also an X newsgroup for more
information.
The critical Xlib files include: the sharable image libX11.a
(or libX11.so, or LIBX11.EXE, or whatever
name.extension your system uses for this type of file), and the header file Xlib.h
(as in #include <Xlib.h>).
In case of broken links
please try to use Google search. If you find the page please notify
us about new location
Compiling Sendmail
docs.sun.com Linker and Libraries Guide
[PDF]
Building and Deploying
OpenSSH for the Solaris™ Operating Environment
Everything Solaris -
Useful Open Source Tools
Copyright © 1996-2008 by Dr. Nikolai Bezroukov.
www.softpanorama.org was
created as a service to the UN Sustainable Development Networking Programme (SDNP)
in the author free time.
Submit
comments This document is an industrial compilation designed and created
exclusively for educational use and is placed under the copyright of the
Open Content License(OPL).
Original materials copyright belong to respective owners. Quotes are made
for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on
this web page are those of the author and are not endorsed by, nor do they necessarily
reflect, the opinions of the author present and former employers, SDNP or any other
organization the author may be associated with. We do not warrant the correctness
of the information provided or its fitness for any purpose.
Last modified:
June 05, 2008
Comments
...
I enjoy reading this blog so I can follow the progress. Thanks for that, and speedy progress!
Posted by: ArmEagle | September 25, 2006 03:28 PM
Because we *choose* to make it difficult...
Chris
Posted by: Chris M | September 25, 2006 03:43 PM
Posted by: digital | September 25, 2006 04:46 PM
Posted by: Todd | September 25, 2006 05:30 PM
It would be nice to see 'lightweight' alternative flash player version without any hardcoded libraries.
This is very important due to security reasons. I can install patch or updated library as soon as it is released. Sometimes in less than 24 hours to keep system protected.
If binary flash will have all libraries builtin, it is wise to not install it, or just remove it when any security/stability bug will appear in one of libraries sticking inside huge flash plugin. Static libraries make programs very big.
I understand that some older systems do not have required libraries and Adobe is trying to reach compability with as much distros as possible.
Flash plugin for windows is not required to be compatible with MS-DOS 1.0 or Windows 3.11 so very old Linuxes should be avoided too.
Linux is not Windows so security is really very important.
For example take a look at skype for Linux. They provide dynamic and static packages.
Posted by: Zbigniew L. | September 25, 2006 05:32 PM
Perhaps the bigger problem lies with the content providers. Why do they require only the newest flash player? Google Video and YouTube work fine with the 7 player. Why can't others follow along? Frustrating...
Posted by: Victor | September 25, 2006 05:33 PM
Posted by: matt w | September 25, 2006 07:22 PM
By the way, this isn't an "off topic" "request" for you to open source the effort. This is an angry rant about the entire existence of your project. You are a jerk for participating, and for expecting any goodwill from the Linux community. I hope you get fired.
Posted by: obviously | September 25, 2006 08:09 PM
Posted by: Huey Van Iadore | September 26, 2006 12:45 AM
I've had similar problems on HP-UX, linking libraries compiled with standard C++ mode (-AA) with others compiled with classic C++ (-AP); short answer is: it doesn't work, and you don't want to deal with the unpredictable problems this kind of setup can cause.
Also, as far as I remember, Adobe offers a custom version of the player for every Windows version you choose, so this wouldn't be much of a pain.
Posted by: Stefan | September 26, 2006 12:47 AM
Posted by: nauj27 | September 26, 2006 12:56 AM
Posted by: Rich | September 26, 2006 03:20 AM
Posted by: Yarick | September 26, 2006 03:28 AM
I heard no one make any claims to even try to synchronise releases of the future versions of flash. Who is to say that by the time flash 9 for Linux comes out (if ever) it will not be made obsolete by flash v25? This seems to be somehow wrong that flash has a built-in windows endorsement all of a sudden.
I only hope a free (as in freedom) alternative or a complete replacement to the flash paradigm catches on soon. It may happen sooner than a current version of the adobe flash for Linux. Until then I will use: “Wine” + “Firefox windows” + “flash 9 for windows”. I know it is a pain but you can actually share saved information such as bookmarks using soft links between the windows and Linux versions of Firefox. It is better than chasing the flash 9 for Linux mirage.
I am tired of seeing people beg for a almost current version of flash for Linux instead of understanding what is happening. Please do not beg, find other legal ways to make an effective protest.
Posted by: arrgh.. | September 26, 2006 05:36 AM
A libstdc++6 dependency is perfectly acceptable for such a modern plugin. The more conservative users will stick with Flash 6 for a long time anyway.
PS
Show some respect towards hardening.
Posted by: Pascal S. de Kloe | September 26, 2006 05:47 AM
Posted by: Vincent | September 26, 2006 05:53 AM
Posted by: SYNERGiST | September 26, 2006 06:32 AM
Posted by: hmm | September 26, 2006 07:14 AM
Open sourcing or simply releasing betas would speed up your effort significantly. The past 6 months I have worked with a few open source projects and the majority of bugs filled in these projects are from the community, not from the developers.
There are a ton of people interested in Flash on Linux. Some of them are hostile and probably won't do anything to help you but a great many more *will*. If betas are released people will file bugs. If the source is released people will write patches.
Also, I suggest reading Eric Raymond's "The Cathedral and the Bazaar" (not the book, the essay). It will reinforce what I've just said.
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/cathedral-bazaar.ps
Posted by: Ben | September 26, 2006 07:40 AM
Ie, what you REALLY want to do is to distribute in a form which can be linked to platform libraries at installation time. GPL zealots will thank you though if you continue with the static linking, but your employer might not...
Posted by: Osma Ahvenlampi | September 26, 2006 07:48 AM
Posted by: baczek | September 26, 2006 08:14 AM
Some people actually need to feed their families. Don't judge someone for working for a company that does not open their software.
As for flash being a cancer on the web: It just proves how good of a product flash is. You can have your opinion and never go to any sites that use flash. No one is stopping you from banning those sites for yourself.
Posted by: Ryan | September 26, 2006 09:08 AM
You provide different binaries for each different version of windows, I'm sure you can have atleast two versions of linux.
Or better yet, open source the player - there is no reason for the player to not be open source. Allowing people to write the player for their own systems gives your format wider reach with lower effort on your part, and then you can concentrate your effort on your authoring suite, thus allowing you to raise the quality of your authoring suite without additional costs.
Posted by: Derek Meek | September 26, 2006 09:20 AM
Posted by: TiCL | September 26, 2006 09:50 AM
Posted by: David Finch | September 26, 2006 11:28 AM
Plenty of other companies release software for Linux, it shouldn't take three years. Yes there are challenges, solve them and get moving or open source.
Hopefully developers will avoid flash like the plague. Especially considering their Linux support history and Linux's growing market share.
I am glad that it is being worked on, but the half hearted effort is disappointing. Sadly you are going to continue to get a lot of crap for your companies poor decisions.
Posted by: Chris | September 26, 2006 11:34 AM
Posted by: Matt Rix | September 26, 2006 11:38 AM
If you statically link to libc++, you need to honor the LGPL requirements : that is, you must offer to provide the binary of flash player for Linux as a set of object (.o) files so that people can recompile them (See the LGPL at http://www.gnu.org/licenses/lgpl.html). The idea behind is that while the LGPL can be used in a proprietary software, end-users must have the ability to change this part of the program to suit their needs.
Posted by: johnelgato | September 26, 2006 11:51 AM
2. how many developers are working on flash for linux vs how many worked on flash for windows?
3. Flash for linux is last app needed by my grandmother, to free herself from the microsoftopoly. How much is money is your employer getting from microsoft for dragging its feet with flash for linux?
4. Do you really feel youve been given the resources you need to make this project succeed?
5. If you do succeed, do you think flash v10 will make youre work a waste of time and effort?
6. What happened to the original promise of simultanious releases on windows/linux/mac?
7. Have you developed on linux before?
8. Do you understand the GPL?
9. Do you have a resume? Can we look it over to decide if this project is just lip service from adobe?
10. Does all this harsh critisism get to you??? Or do you just ignore community feedback?
Posted by: WrongWay | September 26, 2006 12:07 PM
Too bad about all the trolls you get - just know that it's most likely very young kids thinking it's the cool way to behave. In general, not even the hardcore die-hard free software proponents are like that, they just stay away from the program instead. Every "cause" has its (often juvenile) loudmouthed idiots.
Posted by: Stoffe | September 26, 2006 12:13 PM
Posted by: Anonymous | September 26, 2006 12:24 PM
Posted by: webaugur | September 26, 2006 12:30 PM
Posted by: netzkeks | September 26, 2006 12:42 PM
Cf (in any and all source files of the stdlib++ package):
// As a special exception, you may use this file as part of a free software
// library without restriction. Specifically, if other files instantiate
// templates or use macros or inline functions from this file, or you compile
// this file and link it with other files to produce an executable, this
// file does not by itself cause the resulting executable to be covered by
// the GNU General Public License. This exception does not however
// invalidate any other reasons why the executable file might be covered by
// the GNU General Public License.
Linking "statically" or "dynamically" doesn't change anything. So it's perfectly legal (it would be better if Flash was F/OSS, but we know it's not going to happen anytime soon).
Please get a clue before posting. Thanks.
Now, for people asking why it takes so long: surprise, getting software out sometimes takes time; stop complaining, and if you don't care for flash, don't whine :).
They said early 2007, it may be before, just wait and hope YouTube doesn't switch to Flash 8/9 before ;).
Simon
Posted by: Simon C. | September 26, 2006 12:44 PM
Oh, and please, yep, provide versions for different libraries with no stdlib++ within the package. I want Flash to have the smallest memory footprint possible. Please, pretty please? :)
(You can still make the "all-in-one" package more visible on the website, just provide the lightest package possible for users and distributions who know what they're doing. Thanks).
Posted by: Simon C. | September 26, 2006 12:49 PM
Please do not flame Mike or Tinic - while I think all these angry posts have their legitimation, you are "beating" the wrong persons.
Better address that towards Emmy Huang, the Flash product manager. http://weblogs.macromedia.com/emmy/
I am also beginning to wonder what prevents Adobe from releasing a Beta. The whole thing gets more and more smelly. As if the Acrobat Reader ever was perfect when released to the public....
However, since obviously the counsels and not the sales persons dominate Adobe (just think about these ridiculous and (in German law) void restrictions for the Flash specs), I doubt that even Emmy would have the power to change things (if he wanted to do so, what I seriously doubt).
Maybe we should start developing a Gnash like open player in a legislation where the legal restrictions for the Flash specs are void? I mean such as mplayer, libdvdcss etc.?
Posted by: amd-linux | September 26, 2006 12:54 PM
According to the documentation for libstdc++, it is GPL with a special runtime exception clause allowing for binaries to use it without having to be released as GPL themselves. This means its perfectly ok for it to be statically linked with a program that isn't GPL.
Posted by: anonymous | September 26, 2006 12:55 PM
I think it's time to drop libstdc++5 anyway as it is very legacy nowadays.
I remember the stink when some distro kernels went to 4k stacks and everyones nvidia driver broke as a result.
Sometimes you need to force progress.
Thos who have to have libstdc++5 can stick with an older version of flash.
I think the underlying matter is that these flash developers are under-resourced and they dont want to admit it. Adobe probably doesn't see the value in giving themthe resources to make this product happen in a reasonable time frame.
Posted by: Gavindi | September 26, 2006 12:56 PM
Then you could release your plugin with a libstdc++6 dependancy and say go to this-or-that URL if the player complains that libstdc++6 is not found on your system.
Posted by: k12linux | September 26, 2006 01:23 PM
I'm looking forward to the Flash 9 Player for Linux. Flash has a large user base making it easy to reach the users we want at the current company I'm working for. On top of that Flash is not just locked to one platform so everything I develop will work under Windows, MacOS X, and sooner or later Linux.
Posted by: Erick Feiling | September 26, 2006 01:24 PM
That might solve some of your versioning worries now, but
they're just going to lurk in a dark corner like the child locked in a cupboard,and come back to bite you really hard down the line.
And that's assuming that the plugin only exports the symbols it needs to, so
you don't end up with the program binding against the private version of
libstdc++. That'll cause many problems, as you end up calling functions in the plugin version of libstdc++ with data formatted for the system version, which may well be imcompatiable, and hence the computer will end up talking the language of Chaucer to a modern englishman. Kinda.
Do you mean have ld.so link it in, or load it with dlopen? If the latter, then
how are you going to handle loading a different major version of the library to the one you linked against? If you're going to punt, then why not just use ld.so and weak references?
If you're going to do this, then the version of libstdc++ you link the plugin against should be compiled with -fPIC (to generate position independant code).
Posted by: Ceri Storey | September 26, 2006 02:02 PM
Posted by: Jon | September 26, 2006 02:04 PM
also, they have to ensure that as many people as possible can install and use the plugin, because if it only works on 1 or 2 distros, then it would be a huge waste of time.
Opera DOES NOT offer different binaries per distro, it's the same binary... just packaged differently... deb's for debian and ubuntu, rpm's for redhat and suse, and so on...
please cut the developers some slack, he posted a blog so people won't be completely in the dark about the status of Flash9 for linux... appearently he cares
Posted by: freddfx | September 26, 2006 02:16 PM
The whole episode has been a marketing nightmare if you ask me. You've alienated a good portion of the Linux crowd by saying our platform is too difficult to deal with and you folks don't really know when the hell you plan on releasing it to begin with.
I for one will not beg a company to let us beta test their software - not one that has treated us in such a shitty manner.
So how's this, take your time in releasing Flash for Linux. Perhaps we'll give a shit awhile after the release. Maybe just maybe I'll consider using it again. As of right now I'm disabling Flash on my home desktop, my ibook and my office computer.
Posted by: macewan | September 26, 2006 02:32 PM
AMD-linux: it's hard to do that if you don't know the internals of the program. It's only a matter of time though before the Gnash hackers surpass Flash in functionality/speed. And thanks for mentioning that manager, it appears someone is going to have a full inbox.
Posted by: 1c3d0g | September 26, 2006 02:37 PM
Erick: Let's suppose that you access the penguin.swf webpage using IE. For completely arbitrary reasons, the page is translated into Chinese. You get a message that says, "Use Linux to access this page." Adobe has declared war on Linux by choosing to make the internet inaccessible. For some reason they like to support Microsoft's monopoly and when you limit people's choices, that gets them upset.
Posted by: lmf | September 26, 2006 02:48 PM
i'm surprised you don't just release a beta (call it an alpha, if that makes you feel better) for a nice modern stable distro like ubuntu and learn from the hackers that try and get it working on other distros. they will perhaps have to make strange ugly maneuvers, but you can do more graceful equivalents from the other side of the compiler.
stand on the shoulders of giants, or at the least, some backroom hackers.
by setting yourselves the goal of supporting a wide range of distros with your closed project, you are taking on the task of maintainer for all of those distros. most developers don't even take care of this themselves, they leave it to a downstream maintainer.
Posted by: pix | September 26, 2006 03:42 PM
Thanks Adobe for considering such an insignificant market share. Thanks Mike Melanson for ignoring all of the ungrateful jerks out there.
Posted by: Jonathan | September 26, 2006 04:18 PM
There have been lots of companies in the past that have tried to take their crusty in-house build systems and make portable Linux binaries. Invariably they find that their build systems are inferior to the standard automake system. And in the end, they will normally conclude that the best way to distribute the software is as a separate package for each major distribution or as a shell script that rebuilds/relinks the software on the user's machine.
Posted by: jwb | September 26, 2006 04:26 PM
Besides it has nothing to do with MS monopoly, Flash Player has always worked well on Mac OS for obvious reasons, and is not available on linux for obvious reasons as well.
Posted by: proteus | September 26, 2006 04:35 PM
Well, aren't you a total asshole. It has repeatedly been said on this thread that statically linking libstdc++ is perfectly legal but you choose to ignore that just to spread more FUD.
Where's the heavier comment moderation we called for a while ago?
Posted by: Bloody | September 26, 2006 05:07 PM
Go back to Slashdot already with the rest of the anti-Flash trolls.
Adobe may be slow with the Linux Flash player, but so was Macromedia with Flash 7. Looking forward to the public beta...
Posted by: Rob H. | September 26, 2006 05:09 PM
Posted by: Apage43 | September 26, 2006 05:25 PM
Posted by: freddfx | September 26, 2006 05:46 PM
Posted by: ahron | September 26, 2006 06:08 PM
Posted by: El Loco | September 26, 2006 06:41 PM
*hopefully* this will come out soon, cuz I wanna play Dofus without sound lag. (speaking of Dofus, you guys need to fix the bugs that make Flash 9 incompatible with it before you release Flash 9 for linux XD (so much for perfect compatibility :P))
Until then, I hope that you are able to release it soon. (and for the love of pearl, please hurry on this, I'd love to see some of the e-cards my friends send me)
Posted by: rummik | September 26, 2006 07:35 PM
I'm just glad that the developers are trying so hard b/c i know from a practical standpoint adobe has nothing to lose if it dropped it's linux flash player right now. (not to say that in the future they won't need one... when linux rules the world...)
Posted by: Abbas Khan | September 26, 2006 08:28 PM
If you want to be juvenile and vent at someone then find the pencil pushers in the upper management who have a say in these matters and fill up their inboxes. I only hope the management read these comments and take them to heart. Although, I am sure the pencil pushers there in adobe get paid big bucks whether there is a Linux version of flash 9 or not and they do not give a flying rats ass about the Linux or its users.
Posted by: Arrgh.. | September 26, 2006 09:51 PM
Posted by: Phy | September 26, 2006 10:46 PM
Instead of making the plugin work with many different distros in many different config, couldn't you just build one good enough build that compiles in your Gentoo stable arch machines, and then tell the distros how they should work with the plugin?
It's easier to give everyone the prerequisites to make your program work with then than you try to please greeks and trojans at the same time.
Posted by: Bruno | September 26, 2006 11:29 PM
You ought to do that. It makes sense, it's easy and it covers everyone. Yes, idiots may not understand which one to download, but you could just link the right version to the right distro; like 'fedora core 5 download here' would link to the right libstdc++
Surely that makes sense!
Posted by: John | September 27, 2006 02:03 AM
Mike and everyone @ adobe linux team - just do it right, don't listen to crybabies - their cries are nothing more than kid's disappointment his flashy (sic :-) new toy isn't right here right now. Community of grownups patiently waits .
Posted by: Yarick | September 27, 2006 02:42 AM
Sounds to me like they want to see this fail miserably. Where did they get this guy? Can't even load a linked library? Doesn't use automake? These are simple problems to pretty much any seasoned linux programmer.
Posted by: Anonymous | September 27, 2006 04:35 AM
Besides it has nothing to do with MS monopoly, Flash Player has always worked well on Mac OS for obvious reasons, and is not available on linux for obvious reasons as well.
Do you know how this whole flash thing works? They give away the player and make money by having websites that use flash. And how many mac users are out there? Most studies show Linux with a bigger market share than Mac. They want to reach an audience that uses multimedia heavily. Are you really telling me that elementary school teachers are the heaviest multimedia users? There is no "ROI" calculation that would suggest mac is better than linux. When you make the web inaccessible to linux users, yes, you have declared war on them, even if that is a result of complete indifference to linux. Monopolies make everyone worse off, not just existing linux users.
Posted by: Anonymous | September 27, 2006 06:11 AM
Posted by: Fenix | September 27, 2006 09:02 AM
Of course, I bet those licensees get access to the source code in order to build their own specialized versions of the Flash Player :)
Posted by: jwb | September 27, 2006 10:50 AM
Posted by: NoTiG | September 27, 2006 11:17 AM
I actually had some hopes that Adobe was going to to succeed in releasing Flash 9 in a reasonable time period a few month back. Sadly though, that doesn't appear to be the case at this point. Seriously, some of these "issues" that are holding up the release are just instances of Adobe making things much harder than they actually are. Listening to their endless excuses, one would think that they were porting all their applications to Linux, rather than just a browser plugin. Mean while, whole distributions will be born and developed in in the time it has taken Adobe to release a measly browser plugin. What a disgrace.
Mike, I have nothing against you personally, but I think Adobe has set you up to fail terribly by not providing you the necessary resources to complete this task and not really taking your project seriously enought to back it effectively. Ultimately, I think if and when Flash 9 for Linux is actually released, version 10 for Windows and Mac will have already been released or imminent, rendering your current work osolete and starting us on the same drawn out path all over again.
Posted by: jbus | September 27, 2006 11:28 AM
just getting mighty tired of the "you don't have the right flash, get it here"
Nowadays I get these about hourly ..
booo at Adobe
Posted by: q | September 27, 2006 12:55 PM
With this in mind, the libc 6.0/5.0 problem need not be your worry.
Let the packagers put a 6.0 dependancy in their package and leave it at that.
At least do a dynamically linked version for package maintainers to use.
Posted by: Samn Liddicott | September 27, 2006 01:17 PM
NoTiG as for your comment you have to stop looking at the Adobe Flash 9 Player port like the WINE or Mono projects under Linux. As for right now Adobe Flex is really the only tool that compiles stuff out in Flash 9. Even if a Flash 10 Player comes out you think it would be hard for them to use the Flash Player 9 code base and update from there?
I for one do not stand beside Linux/GPL zealots when it comes to trying to open source this plug-in. In most cases a lot of Open Source developers are being paid by some of these big companies like IBM,Novell and even Red Hat to work on an Open Source project. It's not like I don't understand the joys of Open Source software. However not like most people on this form I do understand that these developers need to make a living.
Now could Adobe Open Source the Flash 9 Player and pay these developers to work on it still? That's something I really don't know and the people on this form should ask Adobe that. The only thing I would really want to ask is for a 64-bit and maybe even a PPC Flash plug-in. Now, I don't own an old Mac but it's still about reaching more people. I don't see why people are not even pushing for that.
Posted by: Erick Feiling | September 27, 2006 01:30 PM
-----------------
Releasing Adobe Flash Player for GNU/Linux distros is difficult because is not free software.
Period.
Posted by: ricar | September 27, 2006 02:46 PM
I really don't want to contribute to a flame war about the GPL and libstdc++, but I do really hope you make sure it's legal to distribute your propietary code statically linked to that GPL+exception code. Because for what I understand, it's legal to dynamically link to it, but not to distribute it statically linked with propietary code. That goes against the very core of the GPL.
Here's what they say about the exception:
http://www.gnu.org/licenses/gpl-faq.html#LibGCCException
My advice: drop libstdc++.so.5 and link dynamically to the latest one. I can't imagine any desktop user using the old one and still wanting flash player 9.
Posted by: GNEMAN | September 27, 2006 08:01 PM
The trolls should get a life, too. Flash Player 9 for Linux is not vapourware, and it cannot be open-sourced. Operationally, it is a success; now the installation issues must be addressed.
If Flash Player 9 was "another Duke Nukem Forever", then it wouldn't have been demonstrated to a large crowd. Adobe has made a committment, and upped the ante.
And let's face it, if we're nice, Adobe might consider getting a larger team to port Flash (the authorer program) to Linux too.
Posted by: Chris Lees | September 27, 2006 10:07 PM
Mike, you're doing a great job. Keep up the good work.
Critics: Not having binary compatibility across distro's is a bug, not a feature. Automake is a workaround, not a better design. And if you think flash is so evil, provide me with an alternative, because I've looked at them all (gnash, svg, ...) and none of them do even half of what I need for my projects.
Posted by: Joeri Sebrechts | September 28, 2006 02:42 AM
Now I'm not knocking the Adobe Flash Linux team, but it does appear they all have little Linux development experience. Given this fact and the fact they are forced to work closed-source, I think they are doing exactly the right thing by seeking help from the Linux community. I really hope they listen hard to what everyone has to say as we then might actually see a decent FP9 come to Linux, within a sensible timeframe and something that is fairly easy for Adobe to update and maintain.
Posted by: Jethro | September 28, 2006 02:55 AM
Everyone who reads this, please help promoting and completing Gnash, the free (as in freedom) replacement for Adobe Flash.
http://www.gnu.org/software/gnash/
Posted by: Robert Millan | September 28, 2006 03:27 AM
Posted by: Keith | September 28, 2006 04:24 AM
Posted by: Sync'd Release across platforms | September 28, 2006 04:38 AM
You're absolutely right, I couldn't agree with you more. I would like to personally thank you for having the courage to flood the poor Linux developer's blog with these wise and insightful comments. This is, of course, the best place to put them -- no one could be more responsible for the horror that is Flash than this man. I appreciate you not harassing the pencil pushers telling him what to do, or the webmasters who implement Flash; they have nothing to do with the problem. The sole cause of all our problems is the only guy seemingly working on the Linux version, and I totally agree that harassing him with accusations of incompetence will definitely make Flash happen faster, and make everyone appreciate the principle and people in the Linux community. Again, thank you so very much for standing up for what being an asshole implies you should believe in. I assure you that you do not go unapperciated. Amen, my brothers, amen.
Posted by: Arren Lex | September 28, 2006 10:57 AM
Posted by: Jonathan | September 28, 2006 11:04 AM
No one is forcing you to use flash. Some respect man!
As for Mike and friends, I get the impression that you are making this harder that it really is.
First, distros could find ways to install the player, second you are FREE to exclude folks wo/ some-freaking-library.
AND, it's not that you're asking install std++ v4 Alpha XXX Build to run the player.
Focus on performance stuff, asm stuff, etc... NOT library versions and distro incompatibilities.
AND please erase any silly/disrespectful comments from your minds .
Keep up the good work.We need Flash 9 to get by.
Posted by: Ogla Sungutay | September 28, 2006 11:10 AM
The way I see it, a lot of webcontent is in flash, and it's frustrating, certainly to people that want to use Linux without being pro's. And we all want to be able to see the latest trendy clip when we hear about it.
Most of the heated reactions just indicate the desire there is for this software.
Who's to blaim? Surely the content providers are to some extend. However flash does presents itself as being cross platform. Many content developers count on the fact that other OS's follow withing a reasonable amount of time.
What is reasonable? Surely this is where most debate is about.
Some flame 'hey it is free' so you should shut up. This is a rediculous radical view, it would be the same as only supplying food to people of a certain religion in a refugee camp.I believe most people would aggree it's normal that linux is supported within a reasonable amount of time.
personnally I deem it reasonable if it is there within say 6 months or so.
I sure as hell don't blaim you two, who are developing/porting the flash player.
A critic might addapt the view that adobe is putting just enough money in porting to stay ahead of FLOSS solutions which would not carry their brand.
This blog is a friendly interface, but it isn't the end of the world.
Either you support it cross platform, and then you can't deny that Linux is a player.Or you don't, I don't like this hibrid situation.
Posted by: curto | September 28, 2006 01:03 PM
The general recommendation is to release and just state dependencies as others have stated
Posted by: Christopher Warner | September 28, 2006 01:44 PM
A single binary is necessary because of Firefox's new plugin-handling architecture. If you start with a fresh install of the newest version of firefox, you can (and should be able to -- it makes the user experience consistent across operating systems) just point-and-click install the current version of Flashplayer 7 for Linux, no distro installer, no scripts, no hassle. In fact, this is the *only* way it can easily be installed on a multiuser system on which the user doesn't have root access -- a distro-specific binary would, by definition, require the user to be able to tinker with the OS package manager, something which we can't all do at work.
I do agree, though, that Adobe should be *very* careful with the licensing terms of the c++ library. It would be bad for future Adobe Linux projects to have Eben Moglen on their ass. And it really might just be easier to link agains the version 6 library -- those who said that systems that use version 5 are obsolete are right, in that the only ones that still use that are very conservative, usually server/cluster machines. Any desktop will be fairly up to date. (This is the upshot of not paying the $500 Microsoft Tax for an upgrade to the operating system!) Any desktop system that's not up to date ought to be, by all rights.
Please try not to let the zealots get to you. Quite a few of us use Linux because of the control we can have over the system, not because of any philosophical motivation. We just want it to work.
And I should probably note that we're likely to be a lot less in-your-face than the other crowd. Just because they're vocal doesn't mean that they speak for us all.
Posted by: bdrell | September 28, 2006 02:58 PM
= = = = = = = = = = = = = =
I say we use closed source drivers, closed source software and closed formats and standards since its obviously a waste of time explaining the adage asking an inch and taking a mile.
Its a slippery slope like the guy who says hes just gonna try heroin once. It wont hurt you once...but after that its another story.
Your atittude will never force Adobe to get off their effing ass.
Adobe's atittude reminds me why closed formats are bad.
Whether theyre vital or just eyecandy.
And to they guy from CRN who has nothing else to write about but trolls on a blog: "Whaaaaaaa, he's being me to me.....Whaaaaa, I want my mommy!"
If any software is hindered by what some douchebag like myself says about Adobe on a little blog, then maybe you should unplug your computer and chuck it in the river.