May be. But as a realist you should check your facts first, before jumping to conclusions.

We have. May be you try it yourself: http://slackware.osuosl.org/slackwar.../ChangeLog.txt
Looks like enough action.

Instead of whining about a website that is down and jumping to conclusions: Again, check your facts. You should have read this thread and the explanations in it.

Again, you haven't checked your facts: What we know is that there are currently major changes in -current. What we also know is that Pat releases a new version only when it is well tested. And also that Slackware has no fixed release schedule.
These are the facts. Where do they imply that Slackware is dying?

Nothing strange with that. You didn't check your facts, so you really can't be a realist. People that are spreading FUD without any base are normally called trolls.

See it as that: If you want a distro where every change is announced in literally dozens of blogs and that has a fixed release cycle then go for Ubuntu or Fedora. We Slackers prefer well tested and stable systems and don't care about marketing messages in blogs. Changelog.txt is enough information.

Now back to syncing my mirror and upgrading my systems.

2 members found this post helpful.

You can install libffi from slackbuilds which will give you a usable version of the library. The version included in gcc is for gcc to use, not for external use.

I see in the other thread you complain about the location of the include file, this is by design and not an error.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23935

Yes, actions speak louder than words. We've got a huge batch of updates in -current. I've upgraded this morning and am running a very stable system. What more would I want? I don't know how much you know about Slackware, but please note that Slackware -current is not eg. Fedora-rawhide where updates are much frequent but most often break things so running Fedora-rawhide is REALLY for brave people. For the record, I have nothing against Fedora. They just have a different testing model than that of Slackware. Here Pat and the rest of the crew do the initial testing and only then give us the opportunity to do further testing.

So what? Slackware website is not the Slackware operating system. Slackware does not run a marketing campaign that would rely on their website. The way new users learn about slackware is different than that of eg. Ubuntu (where their website is full of marketing slogans and trendy buzz words. Slackware doesn't rely on its websites (it's the mirrors that count). I admit it's not an ideal thing that the website is down, but it's not the end of the world.

No new release?! Well, sorry to break it to you but Slackware is not Fedora/Ubuntu where releases are frequent and scheduled. Don't like the release model, change your distro and stop spreading crap.

If you expect a "Pat" on the back for spreading nonsense, I'm afraid that's a wrong forum. YOU get over it.

2 members found this post helpful.

And I'm a slacker from, I believe, version 0.9something. And I love Slackware. There's only one thing about Slackware, I actually hate - it's this "it's ready when it's ready".

Simple fix: Run Slackware -current instead (but be aware, -current is never ready) if you want to have newer software, or go to a distro like Ubuntu when you rather want to have a fixed release cycle than a stable system.

I never said it was an error, just that I didn't understand why they were in such a strange place.

Anyway, Thanks for the link Wildwiz. I now see that having the ffi include files in /usr/include would be a problem if there is a need to support the concurrent installation of multiple versions of gcc each with their own version of libffi, so that explains why they did that with the includes.

However the introduction of a libffi package on Slackware introduces a collision with the contents of the gcc-java package: specifically the /usr/lib${LIBDIRSUFFIX}/libffi* files. Having package installation order become significant is something I don't like and try and avoid wherever possible. This is why I thought of manually adding a libffi.pc file and using the libffi that was shipped with gcc as the system-wide libffi. And it seemed to work ok. Is there actually any problem with doing it this way?

@GazL: after your hint of simply creating the pkgconfig file I've done the same and no prob so far

All of the libffi files shipped in the gcc-java package should be removed before compiling anything that links libffi, or else you will get some binaries that link both libffi.so.4 (shipped with gcc-java) and libffi.so.whatever is in the standalone package (3.0.10 ships libffi.so.5 while 3.0.11 ships libffi.so.6 - I hope every release doesn't bump soversion).

As I stated in another thread, gcj links libffi statically, so there's absolutely no reason for the libffi stuff to be included in gcc-java at all, and we'll get that fixed before it's relevant for the distribution as a whole

---------- Post added May 5th, 2012 at 12:46 ----------

Will glib2-2.32.x build that way too? It wouldn't for me, but even if it will, I still think the better solution is to ship standalone libffi and kill the libffi stuff in gcc-java.

2 members found this post helpful.

I didn't try 2.32, but 2.33.1 built just fine with the hacked together libffi.pc I posted in that other thread.

If the libffi libraries aren't needed by the gcc java stuff post build then I'm all for getting rid of them from the gcc-java package as you say and using the standalone libffi package. My main concern was the risk of unintentional downgrading/overwriting because they are in two different packages. The rest was just curiosity.

I did try rebuilding gcc at one point (after uninstalling gcc-java and installing libffi-3.0.11) adding --with-system-libffi to the configure, but it still resulted in the libffi.so.4 files being created, so that didn't work out (It was pretty much a shot in the dark though)


Thanks for posting Robby. Looks like you guys are on top of this one, so I'll leave it with you.

yes, 2.32.2 built fine, but I'll switch to the standalone libffi, seems better to me too

to say the truth what puzzles me really is gobject-introspection yes/no

Well, I wonder what I did to stuff up 2.32+ building, since it worked for you and Gazl. Oh well, the better approach is the one I ended up with anyway...

Well, for now, it's "no" - but gtk+3 is going to require that anyway, which will mean adding gobject-introspection and rebuilding/updating quite a few components to use it, and then building gtk+3. A lot of this stuff has been just shy of rabbit hole complexity...

1 members found this post helpful.

Glad to hear that libffi issue is going to be solved, as it concerns the project I'm interested in, PyPy, and many more as we can see from recent posts about libffi. Thanks.

Yeah, i have tried building gtk+3 and it does requires gobject-instrospection and many other components
here are the requirements:
- gobject-introspection 1.32.1 (Available on SBo)
- pango-1.30
- gdk-pixbuf 2.26.1
- atk-2.4.0
- glib2-2.32.1
- libffi-3.0.11 (Available on SBo)

You can check my GTK+3 SlackBuild from my SlackHacks repository. It's adapted from Slackware's SlackBuild script

The site of Slackware has been down AGAIN... (at least at this moment when I write this).

What is happening?

Please take the time to read this link -->http://www.linuxquestions.org/questi...e-down-939712/

NO, Slackware is not dying. Stop spreading such fud.

2 members found this post helpful.