Issues with i386 and installing Google Earth

Head_on_a_Stick · 2014-09-14 00:41:18

^ Reference: technical reason why you can't mix sources:
http://stackoverflow.com/questions/3784 … pi-and-abi

BruceJohnJennerLawso · 2014-09-14 21:16:22

Head_on_a_Stick wrote:

BruceJohnJennerLawso wrote:
Im just unsure as to why the newer version of libc6 would cause any major breakage though. The hack I applied updated libc6 from 2.13 to 2.19, which I understand to be still within the same header versions (2.xx), but with just some changes to the source code (optimizing functions, fixing bugs, etc.). Why would programs have an issue with a newer version of the library if the functions do more or less the same things? I ask also because I program in C++, and I want to better understand how linux works with libraries and releases.
TBH it sounds like you know far more about this sort of thing than me -- I'm just repeating advice I have obtained from reliable sources...

The concept is simple really, in C (and C++) code is usually separated into two files, a header and a source file. The header file (.h or .hpp) contains a short description of functions in the given library known as a prototype, something like

return_type function_name(argument_type args);

// ie for the basic trig functions:

float cos(float x);
float sin(float x);
float tan(float x);

and then in your source file (.c or .cpp) youd define a function that accepts the given arguments and returns the type you specified, ie

float cos(float x)
{   // do your stuff in here, probably the taylor series for cos(x)
     return x_value;   // the value of the function gets returned
}

The source code can then be compiled into a library, either static (.a or .lib depending on the os of choice) or dynamic (.dll or .so). .so libraries are really important for linux since they dont need to be included in programs at compile time; the compiler can just take the header files when the program is compiled, and looks for the dynamic library at runtime to see the implementation of a given function. This is really nice because it means that programs dont necessarily have to be recompiled every time a dynamically linked library they use has its source changed, like if you found some sort of better algorithm than the original one for calculating cos(x), or a particular function leaks memory, or causes a crash.

From what I gleaned from a conversation with a friend of mine who has helped me with coding from time to time, the header files of a given library are kept the same for each version number, ie any version of a library that starts with a given number should be the exact same (so 1.01s headers are the same as 1.02, and 1.09, and so on...). When a project goes to the next version number, like 2.0 (or possibly 1.1), the header files may be changed, so our original function cos(x) could now look like

float cosine(float x);   // just to be more specific in how we say it for some stupid reason, the function works exactly the same

which screws up backwards compatibility, making it necessary to recompile the program with new headers for it to work right. The only major plausible reasons I can think of for doing this is to change the formatting style of the functions (thisfunction(), thisFunction(), this_function()......) or for adding new functions, but there are probably other reasons.

To the best of my knowledge, this would mean that 2.19 should in theory be perfectly equivalent to 2.13 for most purposes, although the newer functions could have minor instabilities (the reason why the library is in testing of course wink )

Unless the project is not following this convention, I would guess that everything should be fine (hopefully, kinda, cross-your-fingers) but the package manager shouldnt necessarily have had issues with trying to install things. Maybe it just automatically does this if the library version is ahead of the one that a given package specifies is necessary?

Just thinking out loud here...

Head_on_a_Stick · 2014-09-14 21:21:57

From my link in post #26:

An ABI change is where code that has already been compiled against version 1 will no longer work with version 2 of a codebase (usually a library). This is generally trickier to keep track of than API incompatible change, since something as simple as adding a virtual method to a class can be ABI incompatible.

But you may be right...
smile

Alad · 2014-09-14 23:08:43

To the best of my knowledge, this would mean that 2.19 should IN THEORY be perfectly equivalent to 2.13 for most purposes,

Quoted for emphasis. Use google, or just look 15 minutes through this forum how the practice is miles apart from that. This goes from rabbit hole version conflicts to everything-segfaults-oh-dear-what-now.

One of these days I really have to write a catch-all chroot script. Until then, use a VM or that ugly LD thing.

Last edited by Alad (2014-09-14 23:10:20)

porkpiehat · 2014-09-14 23:19:18

Head_on_a_Stick wrote:

But you may be right...

No, he's not. )-: Verbose, yes; right, not so much.

Last edited by porkpiehat (2014-09-14 23:22:45)

Alad · 2014-09-14 23:56:00

^ I admit I didn't go through his wall of text (his point goes 100% against proven practice, anyway), but if you're willing to expand on that, I'd be interested, at least. smile

Last edited by Alad (2014-09-14 23:57:30)

Head_on_a_Stick · 2014-09-15 06:27:58

I would agree with @Alad & @porkpiehat on a purely empirical basis -- @OP: your system is borked, be sure to post back here when we are proved right...
big_smile

BruceJohnJennerLawso · 2014-09-15 22:39:27

Alad wrote:

^ I admit I didn't go through his wall of text (his point goes 100% against proven practice, anyway), but if you're willing to expand on that, I'd be interested, at least.

Ahh, just to clarify, I wasnt saying that its okay to screw around with these things because the process works like the above in theory™ I was just wondering about the way the process works as a programmer, because I like to understand the whole process.

I wish I had seen your suggestions earlier about alternatives to apt-pinning before I tried it, definitely sounds like a better idea.

CrunchBang Linux

SEARCH

#26 2014-09-14 00:41:18

Re: Issues with i386 and installing Google Earth

#27 2014-09-14 21:16:22

Re: Issues with i386 and installing Google Earth

#28 2014-09-14 21:21:57

Re: Issues with i386 and installing Google Earth

#29 2014-09-14 23:08:43

Re: Issues with i386 and installing Google Earth

#30 2014-09-14 23:19:18

Re: Issues with i386 and installing Google Earth

#31 2014-09-14 23:56:00

Re: Issues with i386 and installing Google Earth

#32 2014-09-15 06:27:58

Re: Issues with i386 and installing Google Earth

#33 2014-09-15 22:39:27

Re: Issues with i386 and installing Google Earth

Board footer