Is an installation/environment issue.

Symbols

Each time you compile a code, once the .cpp is compiled, that compilation unit is transformed to a object code (file with extension .o). Your prueba.o is passed to the linker, which eventually generates an executable (prueba.exe). prueba.o is finally removed, as it is an intermediate object. The linker is actually another different program, called ld, which is used internally by gcc so that you are not the one who performs the two steps manually.

From the linker's point of view, each global variable name, static variable, or function name (either an external function or a member function), of each object code, is called símbolo.

What symbols does your executable have? As all functions of the Class persona, main, all symbols in the file <string>, and all symbols in the file <iostream>, since they are all the files you include in your program.

Well it turns out, there is a symbol of the Class std::string (a std::string is actually a typedef of std::basic_string<char>), which for some reason is not defined in the executable, although at the same time, it is called from the executable itself.

When you try to call that symbol (that method), it does not appear in the executable, hence it tells you that it does not find it. So something wrong is going on in the build/bound process, which symbols are not "managing" well.

Name Mangling

Why does not the name of the problematic symbol come, in the description of the error, written in Christian ? Because, because C++ has overhead of functions and operators, in addition to namespaces, and therefore, there may be functions and operations that are called the same, compilers perform a thing called name mangling.

Fundamentally, it is to give each function / overload a unique name, since the linker "only understands from C", where each name is unique (to put it somehow, that's why the quotes). The names are pensandos to avoid conflicts, and in addition, each compiler, and in each platform performs a name mangling different (from there is the great pollution of meaningless things, usually characters that indicate the type and numbers that indicate the number of parameters or the length of each name). Know the problematic method in particular is impossible, unless you have the name demangler of your platform.

It is likely that when compiling, the compiler gave a name to a function or operator at the call point (i.e. when you use it), which does not match the generated name for the library function.

My hypothesis is maybe you haven't done an installation from scratch, and maybe you've installed the libraries from sources other than the compiler, or you've installed different versions does not successfully, or when you installed the compiler were already certain libraries installed for other reasons, or you've done an update that has not been completed well, etc., Or you may have even versions precompiled of these libraries with the names already generated: there may be a version compiled of <string>, with generated names different to that generated by the compiler at the point of call in your code; if there's a version already compiled, the compiler uses these and skips line processing #include <string>, resulting in the end that the name treatment given to that pre-compiled version, is different from the name treatment given to your file.

In any case, either there are conflicts with the names, or it simply does not compile well and the member function does not even exist or has disappeared.

Conclusion

Your code is correct, and your build line is correct (I've compiled on my own and runs correctly), so the problem is 100% environment safe.

So you have to reinstall everything, or better yet, work on a clean virtual machine and install and develop there. Windows stuff. Switching to Linux to develop is also an option:).