Please wait...
Ugh... this is like Goldilocks.
"And this compiler was *just* *right*."
The compiler, the compiler, the compiler is on fire!
We don't need no water -- let the motherfucker burn!
BURN, MOTHERFUCKER, BURN!
HA!
That's a joke.
I can't get Jenkin's client to run on this Valhalla Redhat machine because I can't install a new enough version of Java on it.
It wouldn't take much to convince me that every time a sysadmin logs into a solaris box, god rapes a dolphin in front of the pope.
2014-08-07 13:38 from IGnatius T Foobar @uncnsrd
Valhalla, NY is just a couple of miles away from here. You want me to
drive over and try it?
If you were a god, I could suggest "Entrance of the Gods into Valhalla" as the accompanying music.... <evil grin>
Solaris is the alpha version of Linux for SPARC. Nobody told Oracle that
it was scrapped so they keep shipping it.
Huh.
I am not sure if this is because of something special we're doing with LD_PRELOAD, but it looks like statically linking libs into your shared objects causes the shared object to no longer preload.
I am not sure if this is because of something special we're doing with
LD_PRELOAD, but it looks like statically linking libs into your shared
objects causes the shared object to no longer preload.
missing -fPIC?
Hmm... I'll look into that. That doesn't look familiar.
Fiddly, getting the right command line arguments.
Hmm... I get why -fPIC is needed, and I suspect that's the problem.
Adding it, though, leads to several undfined symbols from C++ (e.g.: _Unwind_Resume).
I note these seem to be undefined within the C++ lib file, which suggests it expects *someone* to provide these, but I'm not sure who.
I could probably work around the problem by creating something to link into everything that just defines all of these as void*... but that feels wrong to me, like I'm missing something else to which I should pay attention.
Well, it's something with which to play.
I note these seem to be undefined within the C++ lib file, which
suggests it expects *someone* to provide these, but I'm not sure who.
libgcc_s I believe.
I did find it in libgcc_eh, which is hidden away in the bowels of the folders somewhere, but the compiler seems to defy including it.
I may try playing with this later. I have something that works, even if it isn't my ideal.
I think I've been trying to work through Linux issues for about a month now, when I was hired to work on Windows, just because the Linux guy we have doesn't seem eager, willing or perhaps capable of looking into this kind of stuff.
But I have a Windows bug I've discovered that I need to address... a nasty crash exposed by doing something our students will commonly do.
(And, yeah, I recognize the first problem is that they're using Windows, but this is a class... we sorta have to let them discover the ways in which Windows sucks, and you can't really do that without Windows).
I did find it in libgcc_eh, which is hidden away in the bowels of the
folders somewhere, but the compiler seems to defy including it.
think you need to link with g++ -shared in order for it to happen automatically.
I did try to link with g++ instead of gcc, but that lead to some other kind of problem... it complained that it could no longer find -lgcc_s, even when I went to the trouble of explicitly adding the path that it already knew about.
and gcc -v or whatever it is that prints the linker command line when it's invoked by the driver.
It's fairly clear that there are some compatibility bugs with respect to this version of gcc and the underlying system library setup...
Heh, well, if it turns out to be a compiler bug, it isn't getting sorted.
It's an older compiler, and I don't really feel like digging into its code to correct it (if there's a problem).
Working through a Windows problem that isn't terribly easy to see. I'll come back to this when I can.