Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Solaris Specific Problems with OSS Linking and Compilation

Old News ;-) See also Recommended Links GCC on Solaris Shared Libraries for Solaris C Solaris specific problems with linking and compilation
Autconfig Make       Humor Etc

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.

Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News

[Sep 28, 2006] Penguin.SWF What's So Difficult

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:

  1. statically linking libstdc++.so.6
  2. 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.

Comments

Ok, so it works. Time for a beta! :)
...
I enjoy reading this blog so I can follow the progress. Thanks for that, and speedy progress!

Chris

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.

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...

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.

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.

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.

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.

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

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...

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.

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.

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.

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?

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.

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

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).

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.?

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.

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.

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.

This is why I wanted to know how to statically link libstdc++.so.6 with the main binary--

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.

dynamically opens libasound.so

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?

These textrels are caused by 2 things in this case:

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).

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

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.

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.

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.

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.

Thanks Adobe for considering such an insignificant market share. Thanks Mike Melanson for ignoring all of the ungrateful jerks out there.

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.

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?

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...

*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)

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...)

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.

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.

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!

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.

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.

Of course, I bet those licensees get access to the source code in order to build their own specialized versions of the Flash Player :)

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.

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

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.

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.

Releasing Adobe Flash Player for GNU/Linux distros is difficult because is not free software.

Period.

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.

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.

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.

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/

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.

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.

The general recommendation is to release and just state dependencies as others have stated

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.

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.

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.

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>).

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

Compiling Sendmail

[PDF] Building and Deploying OpenSSH for the Solaris™ Operating Environment

Everything Solaris - Useful Open Source Tools

Sun's Linker and Libraries Guide

Binary Formats


Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D


Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019