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.
strace is your friend once more.
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.
its simply to clue you up how the g++ calls the linker, and do it the way its right on your own afterwards.
well, as I recall things could get weird when you start mixing up a libgcc_s with a glibc and libgcc setup that originally had it static. So the compiler may not be set up to deal with that very well if at all...
"Maybe rebooting will work."
The actual Linux developer here. He reboots Linux machines almost as if he were a Windows developer.
rebooting / turning off & on again helps if you have bugs with uninitilized values in your software - the memory is flushed and you therefore have a bigger probability they're initialized to 0...
Elseways sometimes if you've got trouble with drivers of i.e. wlan hardware this may help also.
but usually you only masquerade your error further by doing so.
Re-boots are for testing whether upgrades were power-failure and thus reboot safe.
Normally, stopping and starting a service/daemon can accomplish what one seeks to do with a reboot, in my experience, regardless of whether you're working in Windows or Linux.
If we did more work within the kernel, I might understand the rebooting a bit more. And, perhaps, that's why I find his behavior a tad odd... he was a kernel developer, now finding himself in the application space, and accustomed to reboots as a way to clean everything up.
I may find myself trying to resolve this sooner than expected.
The code mostly works, but occasionally has a weird permissions problem when attempting to get a shared memory object for which the permissions were set appropriately for all to read and write.
I suspect a conflict between the libc required for our shared object, and the libc required for whatever executable that runs in our instrumented shell.
The only way to resolve that will be to ensure our shared object is statically linked.
The code mostly works, but occasionally has a weird permissions
problem when attempting to get a shared memory object for which the
permissions were set appropriately for all to read and write.
Hmmmm... is it possible that instead of 'rw-' you may need 'rwx' ??
Just a thought...
Then there's always
File Permissions of the Beast!
Heh... it's already the permissions of the beast. It's permissions on shared memory, though, from which nothing will be executed, so it shouldn't need 'x' permissions. And, normally, it works... just not in this environment with my perhaps funky compiler thing.
Windows. Does anyone know for sure?
We kicked Germany's ass once. Perhaps we need to do it again.