"gcc linker" does not link C++ programs ( gxx_personality undefined ?)
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
"gcc linker" does not link C++ programs ( gxx_personality undefined ?)
Hi guys.
my gcc compiler was just fine for C/C++ programs. I have recently
updated to mandrake 10.0 (from 9.2) and it seems I have misinstalled
something. C programs still compile fine, but C++ programs get all the following
error from ld :
/home/bahram/tmp/ccGA3otm.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status
Now, I have no idea what this `__gxx_personality_v0' is. None of my old programs
compile anymore. Even the simplest test like printing "hello world" fails to compile.
Thank you if you have read this post till there, and even more thank if you can help.
Re: "gcc linker" does not link C++ programs ( gxx_personality undefined ?)
hello, I have the same question.
My OS is redhat AdvanseServer3.0, kernel is Linux 2.4.21-4, share lib is libstdc++-2-libc6.1-1-2.9.0.so and libstdc++-3-libc6.2-2-2.10.0.so . I want to install slurm with maui. I do accoring to that the document describes. After make and make install When I typed \'slurmctld -D\', the porcess exited, and error is reported:
------------slurmctld version 0.4.22 started 1
debug3: plugin_peek: dlope(/usr/local/slurm/lib/slurm/sched_wiki.so): /usr/local/slurm/lib/slurm/sched_wiki.so: undefined symbol: __gxx_personality_v0
error: cannot find scheduler plugin for sched/wiki
error: cannot resolve scheduler plugin operations
fatal: failed to initialize scheduling plugin
so I fail to run slurm with maui.
I use g++ instead of gcc, the error is still occur.
Since you use g++, that's not the problem. I think it might be dlopen (which I assume is meant by `dlope'), but I'm nowhere near sure enough. Might be very slurm/maui-specific.
It has been noticed that sometimes an error message appears when linking object code, where gxx_personality is not found.
The compilers create some object code that at first glance, would appear to be dead code, causing the gxx_personality error message to appear when linking. Actually, the code is not dead code. It serves a very constructive purpose. More details about its purposes are provided later on in this very documentation.
In order for gxx_personality to serve its intended purpose, the changes also needed to be incorporated in a coordinated way with the linkage editor and other software. If an attempt is made to use a linkage editor which does not accomidate gxx_personality, the error message will appear.
When the error message involving gxx_personality appears, then the generated code involving gxx_personality is truly dead code.
There are at least two ways of dealing with this problem. One way is to provide code that resolves the address for gxx_personality. This approach should only be used when the gxx_personality error occurs, and should not be used otherwise. A second method is to strip out the dead code which involves the reference to gxx_personality.
I have not tested the ability to provide code that resolves the address for gxx_personality, because I personally solve the problem by removing the dead code instead. Here are the steps that can be taken where additional code is provided to resolve gxx_personality using cygwin:
First, create source code for VJKgxx_personality.cpp:
// The purpose of this function is to deal with a problem with gxx_personality
Remove the above line also, and keep removing lines until another line is found which starts with:
.def
If no line appears like the one above, then just remove until the end of the assembly language source code.
Finally, assemble the code with the following:
\cygwin\bin\as.exe vjkWhatever.s -ovjkWhatever.o
The resulting object code will link normally.
I remove the code using program VJK00141, which I have written. It makes other modifications to the assembly language source code to make it a better fit for the environment, so here is a stripped-down version, which shows how to deal with gxx_personality:
// Copyright (C) 2007-2009 by Verlan J. Kliewer. All rights reserved.
// This program modifies the cygwin assembly output from compiler/input to assembler
extern "C" int __cdecl main ( int argc, char *argv[ ] ) {
while ( NULL != gets ( &vjkBuffer[0] ) ) {
if ( 0 == strcmp ( "\t.section\t.eh_frame,\"w\"", &vjkBuffer[0] ) ) {
// We strip out some source here
do {
if ( NULL == gets ( &vjkBuffer[0] ) ) {
return 0 ;
}
} while ( ( 0 != memcmp ( "\t.def\t", &vjkBuffer[0], 6 ) ) || ( 0 == strcmp ( "\t.def\t___gxx_personality_v0;\t.scl\t2;\t.type\t32;\t.endef", &vjkBuffer[0] ) ) ) ;
}
puts ( &vjkBuffer[0] ) ;
}
return 0 ;
}
The purpose of gxx_personality
I found no documentation describing the purpose of gxx_personality, but the reason for it is extremely obvious from a cursory review of the generated assembly language code. It is present in object code to provide some improved debugger capabilities. A table of information is created for each of the longer functions detected in the original C/C++ source code. Shorter functions do not have a table associated with the function. The table includes information about the function, including where the function starts in memory and where it ends.
By itself, the enhancements to the resulting object code is not enough to implement the debugger capabilities. There is no conventional way of accessing the information, and it would behave as dead code. Changes to the linkage editor, however, can enable the linkage editor and debuggers to obtain a list of the functions and the tables associated with the functions.
When executing without the debugger, the software is not slowed down, but runs as rapidly as before. It just takes slightly more memory for the tables associated with each function.
In environments where many people maintain and develop the software, such as with cygwin, when problems take place it may be difficult to identify what is happening and which code is responsible in a production environment. The additional debuging capabilities make it easier to vindicate good code and implicate code that needs to be modified.
Thus, developers of good code benefit, because they are vindicated when problems take place. Code that needs to be modified or which actually has bugs also benefits, because areas in need of improvement are identified.
There are some disadvantages associated with gxx_personality.
When a linkage editor is used which has not implemented gxx_personality, an error message will appear for an unresolved reference to gxx_personality. This might also happen when a linkage editor which has implemented gxx_personality is used, but it is executed in such a way that gxx_personality capability is not utilized. There are answers for this problem.
Another disadvantage is that with the added debugger capability, it becomes easier to reverse-engineer code. Often under cygwin, the source code is available anyway, so reverse engineering is not as serious a concern.
Another disadvantage is that with the implementation of gxx_personality, option -mno-cygwin is no longer available. This option is for mingw, which allows code to be compiled and linked, linking more directly to the Microsoft operating system instead of going through the cygwin dll. Removal of this option means that the cygwin dll is required for all the software that is linked under cygwin. This is a distinct disadvantage when more than one software package is used at the same time which require the cygwin dll. Only one version of the cygwin dll can be in memory at a time, and if the different software packages require different versions of the cygwin dll, conflicts will exist and it could be that only one of the packages can execute at a time.
The reason why -mno-cygwin was decommissioned was that the the additional debugger capability will not be implemented without going through the cygwin dll. It is too much to link that capability in its entirety in a separate executable. Also, the additional debugger capability may require further development or maintenance, which would be more complicated and difficult if -mno-cygwin would still be available.
Another disadvantage is the increased difficulty in linking cygwin code using other linkers, such as Microsoft's visual C/C++ linker, as covered above. Until now, it was possible to link code compiled by cygwin's compiler using Microsoft's visual C++ linker, as long as the stack space used by each function was less than about 4k (otherwise references to _alloca would be found and not resolved), and the ability of main programs and other programs which start the executable must somehow be prevented from calling _alloca.
More is needed before linking can be practical using visual c/c++.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.