Boffins untangle why your software builds fail

Dependency errors aren't just the bane of Linux users living the configure-make-install life: they also have a significant impact on developer productivity that could be dealt with in the tools developers use. That's one of the conclusions arising out of a new analysis, carried out by researchers from Hong Kong, the University …

[Anonymous Coward]

Errm, Richard...

« Dependency errors aren't just the bane of Linux users living the build-make-install life »

As a user, I haven't done a single ./configure && make && make install since the 90s.

I take it you're a retro type of guy, still on Slackware 2.1? :-) Mind, I sort of miss the old days when I really was a basic¹ Unix user.

¹ Defined as one whose ever only once wrote his own device driver.

[Anonymous Coward]

Re: Errm, Richard...

Come to think of it, life's got a lot simpler since I stopped doing the build/make/install thing as a developer. I haven't had any compilation errors ever since.

[Notas Badoff]

Re: Errm, Richard...

"... life's got a lot simpler since ..." ... management?

[Anonymous Coward]

Re: Errm, Richard...

"Come to think of it, life's got a lot simpler since I stopped doing the build/make/install thing as a developer. I haven't had any compilation errors ever since."

It's great if a missing dependency can be resolved by installing a deb or rpm built for the distro you're using. If there isn't one then you still have to do the configure/build/install thing.

There's quite a few sciencey / engineeringy type packages out there that distros have no interest in. So they don't maintain a deb or rpm for it. The authors haven't got the time to do a deb and rpm and tarball, so they'll do just one of those. Which means if you want to use it you stand a good chance of having to compile it yourself and sort out whatever dependencies it has manually.

It's all symptomatic of the anarchy that is Linux software installation. There's deb, rpm, tarball. If you start including Eclipse's own installation mechanism, and Python's we're up to 5 already. Though I think Python itself has got several different installation methods (not all of which have a corresponding 'uninstall'...) There is bound to be more that I haven't thought of. Then there's the whole "alternatives" thing; it does an OK job, but it's kinda nuts that it has to exist in the first place.

Most other operating systems have just one single software installation mechanism, which is far saner.

[Anonymous Coward]

Re: Errm, Richard...

Nope. Most other operating systems have a myriad of installation mechanisms. Windows has msi packages, and installers from Installshield and various others as well as various home made "installers" that just copy stuff to various locations.

In a very real sense, any single linux distribution is in better shape installer wise than Windows.

I will admit, though, that it drives me up the wall when the only package for a program I want to use is for Ubuntu and all the documentation is Ubuntu-centric " to manually compile, install Ubunut package x, y, z and compile."

[Snake Plissken]

Re: Errm, Richard...

In a very real sense, any single linux distribution is in better shape installer wise than Windows.

Christ, when was the last time you used Windows?

Windows used to get rightly mocked for DLL Hell, but it has largely overcome that problem with the .NET Framework and GAC, to the extent that even when they change the Framework around and introduce a new GAC (e.g. 4.0) there isn't a knock on problem with earlier versions.

This does still leave the problem of .config files needing exactly the right components. And using NuGet in Visual Studio to keep packages up to date is definitely a throwback to the bad old days of version x.y.12345 being out of date the day after you download it. But Windows has largely been free of stupid DLL version incompatibilities for a while now.

[Anonymous Coward]

Re: Errm, Richard...

I find that life's easier when I use a stable linux distro, even if I have to build a few things the old fashioned way. This is especially so with music/audio, where the apps are rapidly improving (and some aren't even included in distros yet) but you want to stick with an older kernel because the new ones keep breaking things. Even in webdev work, given the choice between an outdated package or config-make-install, I'll sometimes choose the latter. I'm used to it. :D

[eulampios]

Re: Errm, Richard...

Right. And isn't it all a poor generalization? The whole "dependency hell" is not a compiler's problem, it's the ./configure script's job or a packaging system pain. Haven't stumbled upon any of those since ... 2007 on both GNU/Linux and FreeBSD systems. In those cases when compilation had failed the make script would be responsible.

Just as of recently the Debian kernel-package designed for the lazy people (like me) to build Linux kernels. The latest 3.15 kernel didn;t produce a .deb image for me, which would be the first failure in ... the 4-5 last years I personally have experienced? No dependency hell at all, this is a bug, a (bad) combination of one kernel commit and kernel-package). More of the former than the latter, I suppose. Yaaawn, I am too lazy to go into the details really, I had to build 3.14.8 version instead.

[Charles Manning]

"that any Linux user will know"

Wrong by at least 90% or so...

The vast majority of Linux users are Android phone users who have never done any software building at all.

[Chemist]

"hat the same dependency hell that any Linux user will know well"

Any, every, all, few ? Which word should you have used

I call FUD. In almost 20 years of Linux use I've had one program (Cinellera) that gave a lot of trouble ( took all afternoon to sort out the compile) That was in a short period when you couldn't obtain it precompiled. Other than that just a little problem with ffmpeg & kdenlive which need some of their libraries to come from the Packman repository

[Guus Leeuw]

Consider this

Dear Sir,

since google gave what 26 MEELION records to the data set, the analysis is a bit skewed.

If the main conclusion is that there is a "dependency hell" out of this massive data set, then my conclusion must be that the developers at google aren't all that smart.

Regards,

Guus

[NorthernCoder]

Re: Consider this

I suggest also considering the use of the compiler as a search function when you do a change in an API (in a project which isn't too large).

I.e. if you change the number of arguments to a function, instead of grep'ing for the calls to the function, you compile and then go to the places the compiler has pointed out errors.

[Anonymous Coward]

I missed the old days ...

... when I could stumble across a poor distressed soul that had lost 2 days in compiling his quite simple program, completely at a loss why his bunch of debug printf(); statements wouldn't produce no output, no matter how many he put ...

Only to find he was trying to compile his 4 C sources exec with a horribly hacked 500 lines Makefile from XF86 found on the net, whithout having any clue of how make works, and that actually, the .o containing his printf would be from, yes, just 2 days ago, not a single time recompiled after the .c updates !

5 mins later, after binning his Makefile and replacing it with a 5 lines one, written from scratch, the whole bloke universe was again working.

I was really feeling godlike.

Anon. as I don't want some to feel bad :-)

[wowfood]

Re: I missed the old days ...

his bunch of debug printf(); statements wouldn't produce no output

Wouldn't product no output? So they would produce output then?

Sorry, I was confused by your double negative. You see grammar is very important to the Nazi party.

[json]

Re Java Builds...

IDE's already show you if you're missing some packages.. so why press that build key?

[CodeBlaster]

High level language hell

If the world would only go back to using assembly language, all of your build woes (dependency issues, wrong "types", errors because Visual Studio can't compile correctly, etc, etc, etc) would disappear overnight. We'd get tighter, faster code and you could probably get a full operating system and apps running beautifully on a single core 50MHz CPU instead of having all the increasingly bloated crap that spews out of high level language compilers these days. You know, the type that requires quad core 3GHz to run effectively...

That's it, I'm gonna get off my soapbox now. Personally, I blame Bill for most of this nonsense.

[annodomini2]

Re: High level language hell

And some of you think fragmentation is a problem now.

[Anonymous Coward]

It gets even better

No web devs here? So many levels of hell now....

- configure-make-install hell

- linux package dependency hell

- php/python/ruby/nodejs package system hell

- wordpress plugin hell

- browser bug/feature hell

- frontend javascript mix'n'match hell

- css's own special hell

- 3rd-party SaaS soup hell

[bob, mon!]

When more is less

In my experience a lot of Windows packages have less of a problem with missing dependencies simply because they expect their dependency to be missing, and include it (or a link to it) in the installer as well. Wireshark bringing in the winpcap package, things that tell me to install .NET version foobar, stuff like that.

[SVV]

Interesting statistics on time lost to dependency issues

It's been donkey's years since I had to endure the pleasures of makefiles and dll helll when I was a C++ developer, and I am truly glad to have bid farewell to all that.

However, the fact that the figures for problem resolution concerning dependency issues (jar hell) on Java projects are the highest is really appalling. How have all these developrs never heard of Maven? Honestly, it solves all dependency and configuration and packaging issues in a straightforward manner, and gets everyone new to a project up and running in minutes. One of the few development tools I swear by, rather than at.

[DropBear]

However, the resolution time “can vary by an order of magnitude across error kinds”...

So I take it that will make the 12-minute Java error a potentially 12-hour one then...? Must add this one to the handy BOFH excuse list...