tag:blogger.com,1999:blog-40472154244264232752024-03-17T22:42:13.426-07:00Cygwin PortsOfficial blog for the Cygwin Ports project, which ports a wide variety of FOSS (especially X11 desktops) to the Cygwin platform.Unknownnoreply@blogger.comBlogger22125tag:blogger.com,1999:blog-4047215424426423275.post-59488576373474633432013-02-11T22:34:00.000-08:002015-05-20T10:10:12.164-07:00Welcome AboardIn response to a <a href="http://cygwin.com/ml/cygwin/2013-02/msg00109.html">recent inquiry</a> on the cygwin list, I now have <a href="http://rubyonrails.org/">Ruby on Rails</a> working out of the box on Cygwin, and have just <a href="http://article.gmane.org/gmane.os.cygwin.ports.announce/167">uploaded</a> the necessary packages to the Ports repository. To assure proper operation, the newly updated Ruby <a href="http://cygwin.com/ml/cygwin-announce/2013-02/msg00016.html">1.9.3-p385-2</a> release is required.<br />
To get aboard with Rails, install the <span style="font-family: 'Courier New',Courier,monospace;">ruby-rails</span> package and its dependencies, then:
<br />
<blockquote style="font-family: 'Courier New',Courier,monospace;">
$ rails new testapp1 --skip-bundle<br />
(files are installed)<br />
$ cd testapp1<br />
$ bundle install --local<br />
(this will show that existing gems are being used)<br />
$ rails server</blockquote>
<blockquote style="font-family: 'Courier New',Courier,monospace;">
(then point browser to <a href="http://localhost:3000/">http://localhost:3000/</a>,<br />
OR:)<br />
$ unicorn_rails<br />
(then point browser to <a href="http://localhost:8080/">http://localhost:8080/</a>)
</blockquote>
From there on out, you're on your own. Enjoy the ride!<br />
<b>UPDATE:</b> Well, that didn't take long. A <a href="http://weblog.rubyonrails.org/2013/2/11/SEC-ANN-Rails-3-2-12-3-1-11-and-2-3-17-have-been-released/">security advisory</a> was issued yesterday for Rails, so I have updated the Rails packages to 3.2.12 accordingly. The supported method for updating Rails apps for newer Rails versions is as follows:
<br />
<ol>
<li>Open <span style="font-family: 'Courier New',Courier,monospace;">Gemfile</span> in a text editor and update the version number following the
<span style="font-family: 'Courier New',Courier,monospace;">gem 'rails'</span> directive.</li>
<li>Run <span style="font-family: 'Courier New',Courier,monospace;">bundle update --local</span> to update the <span style="font-family: 'Courier New',Courier,monospace;">Gemfile.lock</span> file. Existing gems should be found and used.</li>
<li>Run <span style="font-family: 'Courier New',Courier,monospace;">rake rails:update</span> to update configuration files, using the '<span style="font-family: 'Courier New',Courier,monospace;">d</span>' option to verify changes first.</li>
</ol>
More details on this procedure are available on <a href="http://railsapps.github.com/updating-rails.html">RailsApps</a>.Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-4047215424426423275.post-45205904031809217692012-10-31T01:24:00.002-07:002012-10-31T01:25:34.813-07:00X doesn't always mark the spot <p>I have added X11 proto and library packages for the Win32 (<tt>i686-w64-mingw32</tt>) cross-compiler stacks on both Cygwin and Fedora, as well as for the i686-Linux (<tt>i686-pc-linux-gnu</tt>) stack on Cygwin. This means that it is now possible to compile-test xserver patches for Linux, Cygwin, and MinGW at the same time from one platform.</p>
<p>Unfortunately, building X11 for Win64 (<tt>x86_64-w64-mingw32</tt>) is going to take more work. Win64 is unique among 64-bit platforms in being LLP64 (32-bit long, 64-bit long long, 64-bit pointers), which breaks the assumption throughout the X11 codebase that a pointer can be cast to a long (which works on other platforms, both 32- and 64-bit). The usual solution to this is <tt>intptr_t</tt>, but that is C99 and hard requirements thereon are generally avoided in the X11 codebase. Hence, solving this will require massive patching to the headers (possibly including the addition of a <tt>intptr_t</tt>-like type), and will need to be discussed thoroughly in advance by interested parties.</p>
Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-4047215424426423275.post-70642599091026369362011-12-02T00:20:00.001-08:002011-12-02T01:39:33.098-08:00A Qt hat, isn't it?Fedora users may have noticed that F16 ships with Qt 4.8-RC. While I'm not sure what the rush was, it did cause an interesting problem when it came to the <a href="ftp://ftp.cygwinports.org/pub/cygwinports/fedora-cygwin/repoview/cygwin-qt.html" target="_blank">cygwin-qt</a> cross-compiling package.<br />
<br />
Building anything based on Qt requires more than just headers and libraries; Qt's object system requires code to be processed by <a href="http://doc.qt.nokia.com/4.7/moc.html" target="_blank">moc</a>, which generates additional C++ code for signal/slot handling and the like. There is also a number of other tools which "compile" various types of data into C++ code.
I had been relying on the native tools in qt-devel to do this, since the generated code is not arch-specific.<br />
<br />
The problem here is that moc-generated code is very internal-specific; code generated with one version of Qt will not compile with headers from another version. Since the version of cygwin-qt needs to match that of the Cygwin (Ports) qt4 package, and I have no plans of updating that to 4.8 until its proven stable in conjunction with KDE, this created a bit of an impasse. There was another issue with relying on qt-devel, in that qmake requires patches to build libraries or plugins correctly on Cygwin, which limited cygwin-qt cross-compiling to CMake-based packages.<br />
<br />
The solution to all this was to change the cygwin-qt-qmake package, which had previously just included qmake mkspecs, to provide native-built tools from the same version of Qt as cygwin-qt and with the necessary patches. While <a href="http://doc.qt.nokia.com/4.7/qmake-manual.html" target="_blank">qmake</a>/moc/<a href="http://doc.qt.nokia.com/4.7/rcc.html" target="_blank">rcc</a>/<a href="http://doc.qt.nokia.com/4.7/uic.html" target="_blank">uic</a> are always statically linked with the necessary Qt code, the linguist, qdbus, and qt3support build tools are linked against the Qt libraries; for now, they are also statically linked with their Qt prerequisites.<br />
<br />
The updated cygwin-qt and cygwin-qt-qmake are now available for Fedora 14 and up on both arches, along with an updated <a href="ftp://ftp.cygwinports.org/pub/cygwinports/fedora-cygwin/repoview/cygwin-filesystem.html" target="_blank">cygwin-filesystem</a> to support these changes. Even better, thanks to a patched qmake, I was also able to add <a href="ftp://ftp.cygwinports.org/pub/cygwinports/fedora-cygwin/repoview/cygwin-qscintilla.html" target="_blank">cygwin-qscintilla</a> and <a href="ftp://ftp.cygwinports.org/pub/cygwinports/fedora-cygwin/repoview/cygwin-qwt.html" target="_blank">cygwin-qwt</a> packages.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4047215424426423275.post-47885921286599363522011-12-01T21:03:00.001-08:002011-12-02T12:57:25.865-08:00Spicy VinagreOne of the more eventful version bumps during the GNOME 3.2 update was with <a href="http://live.gnome.org/Vinagre" target="_blank">Vinagre</a>, the Remote Desktop Viewer, which supports a number of protocols via plugins. These plugins used to be managed by <a href="http://live.gnome.org/Libpeas" target="_blank">libpeas</a>, a GNOME framework which makes it easier to develop and manage plugins. However, in the case of Vinagre, it was a bit of an overkill, as the only plugins that were needed were those that shipped with Vinagre itself.<br />
<br />
So, during the 3.2 development cycle, the devs decided to replace libpeas with their own <span style="font-family: 'Courier New', Courier, monospace;">VinagreStaticExtension</span> class. In theory, a sensible move, but they made one major mistake: <i>they never added any code to actually <b>load </b>the plugins</i>!<br />
<br />
Now that got your attention, didn't it?<br />
<br />
Of course, if you try vinagre 3.2 on Linux, you may find that it works perfectly (but we'll get back to that). But only because they used the most unportable, Linux/ELF-centric hack that I've ever seen (and trust me, I've seen my fair share of them). It took me a while to figure it out at first, but here is what they did:<br />
<ol>
<li>the plugin init functions are marked <span style="font-family: 'Courier New', Courier, monospace;">__attribute__((constructor))</span>, a <a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html" target="_blank">GCC extension</a> which causes the indicated function to be called automatically;</li>
<li>the plugins rely on symbols in the main binary, of course, but furthermore...</li>
<li>the executable also relied on symbols in the vnc plugin, and to top it off...</li>
<li>the executable is linked against the plugins!! (If you don't think you misread that, then try again.)</li>
</ol>
In short, the only reason that this worked is that, by linking the plugins into the executable regardless of symbol dependency, the ELF runtime loader would load the plugin as a runtime dependency, at which time the plugin init function would be called due to being marked as a ctor.<br />
<br />
To be fair, technique #1 is also used by LADSPA plugins, and #2 isn't uncommon and can be made to work even on PE platforms. However, #3, while theoretically possible, is impractical with plugins due to a lack of rpath in PE linkage, and relying on #4 wouldn't work at all because with PE only those DLLs whose symbols are required are hard-coded as runtime dependencies. And here's the kicker: <i>even on ELF platforms</i>, <a href="https://bugzilla.gnome.org/show_bug.cgi?id=653558" target="_blank">this doesn't work if linked with <span style="font-family: 'Courier New', Courier, monospace;">-Wl,--as-needed</span></a>.<br />
<br />
Fortunately, the fix is fairly easy: make the plugins static instead, link them into the executable as before, and actually call the ctors in main(). So not only is vinagre 3.2 working and available with the rest of GNOME 3.2 in Ports, but while I was at it, I added <a href="http://www.spice-space.org/" target="_blank">SPICE protocol</a> support as well.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4047215424426423275.post-42835755188303124972011-07-06T01:59:00.000-07:002011-07-06T02:08:21.013-07:00Fedora Cygwin repos moved<div>I have updated the Fedora 14 Cygwin gcc to 4.5.3, and have added the toolchain packages built for F15 as well.</div><div><br /></div>In order to properly support multiple RPM repositories, I had to relocate the Fedora Cygwin repos to Cygwin Ports' FTP area. You will need to manually update the <a href="http://downloads.sourceforge.net/fedora-cygwin/fedora-cygwin-release-3-1.noarch.rpm">release RPM</a> (with '<tt>rpm -U</tt>') followed by <tt>yum update</tt> in order to get the new packages.Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-4047215424426423275.post-31833162527835328772011-07-03T11:52:00.000-07:002011-07-03T14:10:18.034-07:00This Lemur can be found outside of Madagascar<div><i>(alternative tagline: did you realize that <a href="http://en.wikipedia.org/wiki/Malagasy_Hippopotamus">hippos</a> and <a href="http://en.wikipedia.org/wiki/Woolly_lemur">lemurs</a> used to be neighbours?)</i></div><div><br /></div><div>I'm referring, of course, to <a href="http://avahi.org/">Avahi</a>. GNOME relies on Avahi to provide <a href="http://en.wikipedia.org/wiki/Zeroconf">mDNS/DNS-SD (aka Zeroconf)</a> functionality. Until now, that's been missing on Cygwin, and for good reason.</div><div><br /></div><div>In order to deal with anything beyond wide area browsing, Avahi requires low-level networking support, and it currently <a href="http://avahi.org/wiki/DownloadAvahi#Requirements">only has that support for Linux, BSD, and Darwin</a>. Any other platform, and well, you might think you're out of luck, except that we're in good company: OpenSolaris is also a GNOME distro and has been in the same boat. For technical reasons, they chose to make Apple's Bonjour (mDNSResponder) the primary mDNS/DNS-SD service, and <a href="http://src.opensolaris.org/source/xref/jds/spec-files/trunk/patches/">patched avahi-daemon</a> to be a client thereof, circumventing the lack of networking support.</div><div><br /></div><div>It turns out that this solution works for Cygwin as well. A Cygwin-built mDNSResponder wouldn't work for the same reason a vanilla avahi-daemon won't, but the former does work on Windows (as used by iTunes, Safari, and <a href="http://en.wikipedia.org/wiki/Bonjour_(software)#Overview">much more</a>). As for the client, since it communicates with the daemon solely via UDP, a Cygwin-native libdns_sd works just fine with a Windows daemon.</div><div><br /></div><div>So thanks to FOSS, we have a working Windows mDNSResponder, a portable libdns_sd client, and patches for Avahi to use it. The result? A mDNS/DNS-SD stack that works for both Windows and Cygwin seamlessly. The possibilities are endless.</div><div><br /></div><div>This does mean that you need a working Windows mDNSResponder running on your machine. While it is open source (Apache-2.0), it requires Visual Studio in order to build, so you'll need to get that binary from elsewhere. You might already have it, as it comes with the aforementioned Windows software (look for the "Bonjour Service" in Services or mDNSResponder in taskmgr); otherwise you can <a href="http://developer.apple.com/opensource/">download an installer</a> directly from Apple.</div><div><br /></div><div>Existing GNOME components which can benefit from Avahi have been rebuilt to enable this support, and a handful new programs and plugins have been added as well. A few packages (mpd, xmms2, and libdmapsharing, the latter of which is used by rhythmbox) which support either stack use libdns_sd directly to minimize overhead. As for KDE, 4.6.5 is due to be released upstream any day now, so this feature will be added there as part of that update.</div><div><br /></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4047215424426423275.post-36737348686321267092011-03-12T21:03:00.000-08:002011-03-12T21:18:33.261-08:00Fedora Cygwin RPM repository<p>I have uploaded the first stages of the Fedora Cygwin RPM repository for Fedora 14 i686 and x86_64. I have added a <a href="https://sourceforge.net/projects/fedora-cygwin/files/RPMS/noarch/fedora-cygwin-release-1-1.fc14.noarch.rpm">release RPM</a> which will allow installing the packages with Yum or the various PackageKit frontends. Any questions or issues with these packages should be directed to the <a href="https://sourceforge.net/mail/?group_id=99645">cygwin-ports-general list</a> for now.</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4047215424426423275.post-6011846107400469262011-03-11T00:02:00.000-08:002011-03-11T01:21:31.780-08:00Planting Season<p>Well, at least in some parts of the world. But not here, it's still below freezing (although not by much).</p><p>Yesterday, I was testing the two programs in Ports which use GObject Introspection at runtime (<tt>lightsoff</tt> and <tt>swell-foop</tt>), I found that those programs were completely nonfunctional. Not only that, I found that <a href="https://bugs.launchpad.net/ubuntu/+source/seed/+bug/725320">it wasn't just me</a>. But as I dug deeper, I found that <i>everything</i> went wrong at once:</p><ul><li>Pango's typelibs were broken due to <a href="https://bugzilla.gnome.org/show_bug.cgi?id=621718">improperly shipped GIRs</a>;</li><li>The gtk_clutter_init* functions needed some <a href="http://git.clutter-project.org/clutter-gtk/commit/?h=clutter-gtk-0.10&id=0d77c7c">introspection annotations</a>;</li><li>Seed <a href="http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/seed;a=blob;f=2.31.91-g_module_build_path.patch">module loading broke</a> in 2.31;</li><li>The games should have been using <a href="http://git.gnome.org/browse/gnome-games/commit/?id=f355bdc">GtkClutter.init() instead of init_with_args()</a>;</li><li>The games were trying to use a Glib function <a href="http://git.gnome.org/browse/gnome-games/commit/?id=98b73ad">which was no longer exported</a>;</li><li>The games were not specifying <a href="http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gnome-games;a=blob;f=2.32-introspection-versions.patch">which versions of its dependencies</a> were needed, causing the wrong versions to be loaded if gtk3 libraries are present.</li></ul><p>The good news is, four packages and six patches later, the games are working again, and will be shipped in the next upload (hopefully next week).</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4047215424426423275.post-63027702458901263032011-02-17T02:37:00.000-08:002011-03-10T20:43:39.150-08:00Across and Back AgainAs you may be aware, last summer I added cross-compiling support to cygport, resulting in a new 0.10 series. The results so far have been quite promising, with cygwin-based cross-toolchains now available for the following targets:<br /><br /><ul><li>MinGW (<tt>i686-pc-mingw32</tt>), with the basic packages <a href="http://cygwin.com/ml/cygwin-apps/2010-11/msg00161.html">available here</a> pending an ITA, and many more in Ports</li><li>MinGW-w64 (<tt>i686-w64-mingw32</tt> and <tt>x86_64-w64-mingw32</tt>), already in <a href="http://cygwin.com/cgi-bin2/package-grep.cgi?grep=mingw64">the distro</a></li><li>Linux x86 (<tt>i686-pc-linux-gnu</tt>) and x64 (<tt>x86_64-pc-linux-gnu</tt>)</li><li>Solaris 10 x86 (<tt>i386-pc-solaris2.10</tt>) and SPARC (<tt>sparc-sun-solaris2.10</tt>)</li><li>Solaris 11 x86 (<tt>i386-pc-solaris2.11</tt>)<br /></li><li>AVR microcontrollers (<tt>avr</tt>)</li></ul><div>With this improvement to cygport, cross-compiling <b>from</b> Cygwin comes with the ease you would expect from a Linux distribution.</div><div><br /></div><div>This week, I decided it was time to turn things around and make it easier to cross-compile <b>to</b> Cygwin as well. To that end, I have created a minimal Linux-to-Cygwin cross-compiler toolchain for Fedora Linux. Under my "fedora-cygwin" (sub)project, I have posted .spec files and patches to <a href="http://fedora-cygwin.git.sourceforge.net/git/gitweb-index.cgi">SourceForge git</a> and RPMs for both ix86 and x86_64 to the <a href="http://sourceforge.net/projects/fedora-cygwin/files/">File Release area</a>. For now it is necessary to manually download and install the RPMs until I have the chance to figure out how to setup a yum repository.</div><div><br /></div><div>While these packages are mostly based on the work of the <a href="http://fedoraproject.org/wiki/MinGW">fedora-mingw</a> project, there are important differences. I'll admit that these are my first RPM spec files, so I'll gladly take constructive suggestions for improvement, or better yet, git patches. Furthermore, these have yet to be tested beyond building themselves. If you do find these useful, or discover any problems, please let me know through the <a href="http://sourceforge.net/mail/?group_id=99645">Cygwin Ports mailing list</a> for now.</div><div><br /></div>Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-4047215424426423275.post-53903269673898514082009-09-08T22:58:00.000-07:002009-09-08T23:20:00.545-07:00A Time to Introspect<a href="http://live.gnome.org/GObjectIntrospection">GObject Introspection</a> looks to be the future of GNOME language bindings, and the good news is, you need not wait until 3.0 to use it. I have just finished adding all the components currently available to Ports SVN, together with <a href="http://live.gnome.org/Seed">Seed</a>, a WebKit-based JavaScript interpreter which automatically includes "bindings" to any of 30+ libraries which ship with Introspection data.<br /><br />Here is <a href="http://sourceforge.net/project/screenshots.php?group_id=99645&ssid=112518">a screenshot</a> of several Seed examples using the GTK+, Clutter, VTE, and WebKit libraries through GObject Introspection. The LightsOff game shown there will be part of GNOME Games 2.28, but I've made a preview of the latest beta release available. All this will be part of the next upload, which I hope will be this week or next.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4047215424426423275.post-8159979809851614822009-06-24T22:00:00.000-07:002009-06-24T22:08:35.928-07:00Google Gadgets for LinuxI just added <a href="https://sourceforge.net/project/screenshots.php?group_id=99645&ssid=107327">a screenshot</a> of Xfce 4.6.1 with <a href="http://code.google.com/p/google-gadgets-for-linux/">Google Gadgets for Linux</a> (which I <a href="http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/x11/google-gadgets-for-linux/">just finished building today</a>) and Konqueror 4.2.4 running on my new computer. Unfortunately, XWin multiwindow mode doesn't have the compositing support to make GGL look right, but it works fine on a desktop.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4047215424426423275.post-78584402829981444312009-06-17T17:46:00.000-07:002009-06-17T18:20:06.493-07:00The Path of Evolution<a href="http://projects.gnome.org/evolution/">GNOME Evolution</a>, that is. This is one of those packages that has been bugging me for years; it would build but not run. But in the process of buildings <a href="http://www.pimlico-project.org/">Contacts, Dates, and Tasks</a>, which also use Evolution-Data-Server but have very simple interfaces, I discovered that NSS still wasn't working, causing E-D-S to not initialize. So I rebuilt E-D-S and Evolution without NSS, and voila, it runs like a charm.<br /><br />So Evolution will be part of the next upload, albeit without SSL support, together with the rest of GNOME 2.26.2. As for SSL support, as much as I would like to have it, I'll admit trying to fix <a href="http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/libs/nspr/">NSPR</a>/<a href="http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/libs/nss/">NSS</a> again isn't my highest priority right now. (Why can't they use something more normal, like GnuTLS, instead?) As always, <a href="http://cygwin.com/acronyms/#PTC">PTC</a>.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4047215424426423275.post-17345447419786068212008-10-02T23:40:00.001-07:002008-10-02T23:52:45.072-07:00New websiteWhile SunSite.dk has been an accommodating host of an ever-growing Ports repository, recent issues with downtime, responsiveness, and storage limits (albeit generous) have held up progress over the last few months. While I am grateful for all their help, the time has come to find another home.<br /><br />Thanks to the graciousness of a sourceware.org admin, Cygwin Ports has found a new home for the <a href="http://sourceware.org/cygwinports/">website</a> and <a href="ftp://sourceware.org/pub/cygwinports/">package repository</a>. This will allow for easier updating and continued expansion of Ports' offerings. The sunsite.dk package repository has been removed, and all website links now point to our new home.<br /><br />I invite all Ports users to visit the new website, and follow the directions there to update their packages. As always, questions/comments/issues/testimonials/thanks/etc. go to the cygwin-ports-general list.Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-4047215424426423275.post-82017197057383783292008-05-12T11:22:00.000-07:002008-05-12T13:37:23.345-07:00Netscape pluginsWhat does Netscape have to do with Cygwin, you ask? Didn't I just say that anything Mozilla-related doesn't work yet on Cygwin?<br /><br />Fortunately we still have one working browser on Cygwin: <a href="http://www.konqueror.org/">Konqueror</a>. The <span style="font-family:courier new;">nsplugins</span> package allows Konqueror to load and use Netscape-compatible plugins. At the next upload, there will be two such working plugins: <a href="http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/ports/libs/djvulibre/">DjView3</a> and <a href="http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/ports/media/xine-plugin/">Xine</a>. I tried, but failed, to get <a href="http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/ports/media/swfdec-mozilla/">swfdec-mozilla</a> 0.5 working as well; another try with 0.6 will have to wait for GNOME 2.22.<br /><br />Yes, swfdec itself and the swfdec-gnome player are working, but I had to disable sound support. Enabling the OSS sound support would lock up video playback while the audio was playing. In the meantime, at least it works for games.<br /><br />If you're looking to play YouTube videos within Cygwin, a <a href="http://www.linux.com/feature/133157">recent Linux.com article</a> lists several downloaders. FFmpeg support allows the following applications to play the FLV videos: ffplay (<span style="font-family: courier new;">ffmpeg</span>), gxine, kaffeine, kmplayer, kplayer, mplayer, totem, vlc, xine (<span style="font-family: courier new;">xine-ui</span>).Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4047215424426423275.post-42173271577756938212008-05-12T10:29:00.000-07:002008-05-12T11:19:18.421-07:00GtkMozEmbed challengeOne of the biggest things missing from Ports' GNOME is <a href="http://www.mozilla.org/unix/gtk-embedding.html">GtkMozEmbed</a>, nowadays often provided by <a href="http://developer.mozilla.org/en/docs/XULRunner">XULRunner</a>. This would allow adding, updating, or new features for the following packages, among others:<br /><blockquote><a href="http://developer.imendio.com/projects/devhelp">Devhelp</a><br /><a href="http://www.gnome.org/projects/epiphany/">Epiphany</a><br /><a href="http://galeon.sourceforge.net/">Galeon</a><br /><a href="http://kazehakase.sourceforge.jp/">Kazehakase</a><br /><a href="http://liferea.sourceforge.net/">Liferea</a><br /><a href="http://www.monodevelop.com/Main_Page">MonoDevelop</a><br /><a href="http://live.gnome.org/Yelp">Yelp</a><br /><a href="http://search.cpan.org/dist/Mozilla-DOM/">Mozilla::DOM</a><br /><a href="http://search.cpan.org/dist/Gtk2-MozEmbed/">Gtk2::MozEmbed</a><br /><a href="http://www.pygtk.org/pygtkmozembed/">pygtkmozembed</a><br /><a href="http://ruby-gnome2.sourceforge.jp/hiki.cgi?Ruby/GtkMozEmbed">ruby-gtkmozembed</a></blockquote>Besides being extremely large (34MB source), Mozilla has always abused Cygwin as a build platform for MinGW/MSVC. I really don't like it when people do that. Cygwin is a fairly capable platform of its own accord, not just a means to an unrelated end, and treating it otherwise is not just insulting to those of us who use and develop it, but confuses new users to no end. (Which is why I'd be glad to see the end of <span style="font-family:courier new;">-mno-cygwin</span> as well.)<br /><br />But since GNOME starting using GtkMozEmbed a few years ago, I've taken a few attempts at removing all the anti-Cygwin hacks, all ending without a successful build. A recent (partially successful) experiment with Netscape plugins in Konqueror inspired me to try again. Thanks to Gentoo's ebuild, I managed to get a successful build, but it just crashes (although sometimes a window appears for a split second). My gut feeling is that it's a problem in the XPCOM initialization, but at this point it's way beyond me.<br /><br />So here's the challenge for anyone who chooses to accept it: get XULRunner to run. To get you started, here's my <a href="http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/ports/net/xulrunner/">cygport and patch</a>. You'll need GTK+ and the GNOME libs from Ports (with their -devel packages) as prerequisites. The build can be tested with the included TestGtkEmbed.exe, or build and install both <a href="http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/ports/perl/Mozilla-DOM/">Mozilla::DOM</a> and <a href="http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/ports/perl/Gtk2-MozEmbed/">Gtk2::MozEmbed</a> and try the examples. (The latter require <a href="http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/cygport/lib/gtk2-perl.cygclass?r1=1.15&r2=1.16&view=patch">a recent patch to cygport</a>.)<br /><br />If you do succeed, please drop a note to the mailing list with your modified cygport and patch.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4047215424426423275.post-79593960473618347472007-12-03T19:58:00.000-08:002007-12-03T20:04:35.276-08:00KDE and gaminIn the Ports builds of KDE 3.5.8, I enabled FAM (with <a href="http://www.gnome.org/~veillard/gamin/">gamin</a>) support in kdelibs. Unfortunately, the tradeoff has been excessive CPU usage by gam_server, much more than is normal with GNOME. Some <a href="http://www.google.ca/search?q=KDE+fam+cpu">googling</a> showed that this may not be unique to Cygwin, but can happen on Linux as well. While I'd be interested to hear if anyone has noticed any positive effects from the FAM support, at this point, I think I'm going to have to rebuild kdelibs without it.Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-4047215424426423275.post-69649065131600978772007-12-03T19:55:00.000-08:002007-12-03T19:58:21.435-08:00SECURITY: link-grammarA <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5395">security vulnerability</a> has been announced for <a href="http://www.abisource.com/projects/link-grammar/">link-grammar</a>. A version bump to fix this is in CVS, and will be included in the next upload.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4047215424426423275.post-76599068292568836402007-10-11T22:32:00.000-07:002007-10-14T21:29:25.047-07:00PHP on CygwinEfforts to bring <a href="http://www.php.net/">PHP</a> to Cygwin have waxed and waned over the years. One of the big problems, at least with PHP5, was dealing with shared extensions, as discussed last year in <a href="http://www.cygwin.com/ml/cygwin-apps/2006-06/msg00007.html">this thread</a>. Unfortunately the sources mentioned there are no longer available, so unfortunately I didn't even have that to start with.<br /><br />PHP consists of multiple interpreters (called SAPIs) which serve different purposes, e.g. a command-line interface, a CGI interface, Apache modules, etc., together with dozens of extensions written in C, which can either be built in to the interpreter or can exist as loadable modules. Additional C extensions are also available on <a href="http://pecl.php.net/">PECL</a>, which must be built as shared modules, as they are installed after building the runtime.<br /><br />PHP extensions require symbols that would normally be (on Linux) in the interpreters, but that doesn't work for Cygwin because all symbols must be resolved at link time. But if an extension is linked against one SAPI but loaded by another, a segfault will result.<br /><br />The solution is, as is done with MSVC, is to build almost all the core sources into a shared library, then link the SAPIs (with just their SAPI-specific code) and the extensions against the library. Implementing this within the autotool framework took a lot of work to get right, but it looks promising so far: both the CLI and CGI load all the modules, PECL extensions can be built, and even better, <a href="http://gtk.php.net/">PHP-GTK</a> is working.<br /><br />This solution does require a few minor changes to the build procedure for PECL extensions, hence I've added <a href="http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/cygport/lib/php.cygclass">php.cygclass</a> to cygport for this purpose; in most cases, a one-liner 'inherit php' is enough.<br /><br />PHP, PHP-GTK, and several other sample PECL extensions are now in <a href="http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/ports/php/">CVS</a>; the PHP .cygport is heavily commented, which should help make sense of what was needed to make this work, for those who are interested. PHP, with separate packages for each of the standard extensions, as well as PHP-GTK, will be available in binary form with the next upload.<br /><br />BTW, at this point I have no intention of packaging PEAR (pure PHP extension) libraries, as they require no compilation; instead, just install php-pear and install them as on any other platform.<br /><br />If anyone is running Apache, then I would like to hear if those SAPIs are working; please post a comment below or to the mailing list.<br /><br />Enjoy!Unknownnoreply@blogger.com18tag:blogger.com,1999:blog-4047215424426423275.post-86464128707956723532007-10-08T10:37:00.000-07:002007-10-08T10:44:03.975-07:00SECURITY: libsndfileThe Gentoo Security team has <a href="http://security.gentoo.org/glsa/glsa-200710-04.xml">announced</a> a security vulnerability in all versions of <a href="http://www.mega-nerd.com/libsndfile/">libsndfile</a>. I have rebuilt libsndfile with their patch, as well as for the new FLAC API. This is now in <a href="http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/ports/libs/libsndfile/">CVS</a>, and will be included in the next upload.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4047215424426423275.post-69205994970552007022007-10-07T19:47:00.000-07:002007-10-08T11:16:32.668-07:00Pidgin and SILCI just <a href="http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/ports/gnome/pidgin/pidgin-2.2.1-1.cygport">finished</a> building <a href="http://pidgin.im/">Pidgin</a> 2.2.1 with <a href="http://silcnet.org/software/download/toolkit/">SILC</a> support. But I came across an interesting problem:<br /><br />SILC can either use <a href="http://gmplib.org/">GNU MP</a> or its own code for multiple-precision arithmetic, and that causes the problem, because "silcmp.h" begins with:<br /><br /><blockquote style="font-family: courier new;">#ifdef SILC_MP_GMP<br />#include "mp_gmp.h"<br />#else<br />#include "mp_tma.h"<br />#endif</blockquote>Only one of those "mp_*.h" headers will be installed, depending on which MP is enabled. But that means that anything building against SILC needs to know if GMP was used or not; if it was, and you don't <span style="font-family:courier new;">#define SILC_MP_GMP</span>, then you obviously get errors at compile time (since mp_tma.h is not installed in that case).<br /><br />For Pidgin, I just worked around this by adding <span style="font-family:courier new;">-DSILC_MP_GMP</span> to <span style="font-family:courier new;">CPPFLAGS</span>, but there should be a better solution:<br /><br /><ol><li>The best solution would be for SILC to add this flag to silc.pc via an <span style="font-family:courier new;">AC_SUBST</span>.</li><br /><li>Otherwise, Pidgin (and other software depending on SILC) should be calling in configure.ac:<br /><blockquote style="font-family: courier new;">CFLAGS_save="$CFLAGS"<br />CFLAGS="$CFLAGS $SILC_CFLAGS"<br />AC_CHECK_HEADER(mp_gmp.h, silc_mp_gmp=yes)<br />CFLAGS="$CFLAGS_save"<br />if test "x$silc_mp_gmp" = "xyes"; then<br />AC_DEFINE(SILC_MP_GMP, 1, [Define if SILC uses GNU MP])<br />fi</blockquote></li></ol><br />Now you understand why the first solution is much better. But does anyone know how other distros deal with this? <a href="http://cygwin.com/acronyms/#PTC">Comments Thoughtfully Considered</a>.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4047215424426423275.post-64380368077854085852007-10-07T19:34:00.000-07:002007-10-07T19:39:59.963-07:00New blogAs it seems that blogging is becoming more common among open source projects, I decided it's only fitting that Cygwin Ports should join the club. Don't expect long essays here, but I will try to share my experiences from building and maintaining a wide variety of software on a not-so-common platform.<br /><br />Also, this isn't meant to be a support forum; keep using the cygwin-ports-general mailing list for that.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4047215424426423275.post-2448976689476933352007-10-07T19:29:00.000-07:002007-10-07T19:34:15.422-07:00SECURITY: xfsX.org has <a href="http://lists.freedesktop.org/archives/xorg-announce/2007-October/000416.html">announced </a>that xfs (<1.0.5) contains several security vulnerabilities; an update is already in Ports CVS and will be included in the next upload.Unknownnoreply@blogger.com0