I have a sun server with Solaris 10 SPARC installed.
I have successfully installed libevent as well as openssl using tarball source code. I am trying to compile tor-0.2.5.16 using gnu gmake. I have encountered the following problem on my solaris terminal as follows
CCLD src/test/test
Undefined first referenced
unsetenv src/test/src_test_test-test-util.o
setenv src/test/src_test_test-test-util.o
ld: fatal: Symbol referencing errors. No output written to src/test/test
Where do I go from here?
setenv() and unsetenv() are POSIX 6/SUSv3/XPG6 functions. If you have an older installation of Solaris 10, it may predate POSIX 6 and may not have setenv() nor unsetenv(). /usr/include/stdlib.h will have something like this in it if your installation has setenv() and unsetenv():
#if defined(__EXTENSIONS__) || \
(!defined(_STRICT_STDC) && !defined(__XOPEN_OR_POSIX)) || \
defined(_XPG6)
extern int posix_memalign(void **, size_t, size_t);
extern int posix_openpt(int);
extern int setenv(const char *, const char *, int);
extern int unsetenv(const char *);
#endif
Note that to use the functions, you have to have specific values #define'd. Do not try to #define these directly. Per the standards.5 man page you have to #define or use the -D compiler option _XOPEN_SOURCE=600. And you must not define _XOPEN_SOURCE_EXTENDED at all. If _XOPEN_SOURCE_EXTENDED is defined along with _XOPEN_SOURCE, you will get SUS/XPG4v2 and not SUS3/XPG6.
I tried OPENCSW gcc-4.6.3, I didnt work either. That being said I have succeeded in compiling and installing tor-0.2.4.20 instead. You were right. It was an issue regarding the GCC compiler I was using (too old) so I had to use an older version of tor instead. Thanks for your help though. Much appreciated!!! I may need asistance in getting gcc-9.1.0 tarball installed though. Will start a new thread if I encounter problems. :) :)
Related
I have recently installed PARI library on ubuntu 16.04. The set of examples provided with the source are running correctly but , if I use "gun", "ghalf", etc., gcc compilation fails with error :
error: ‘gun’ undeclared (first use in this function)
I am new to this library and know very little about it. Can anybody please help me in fixing this error.
This is the code that I am trying to compile :
#include<stdio.h>
#include <pari/pari.h>
int main(void)
{
GEN i,j,k;
pari_init(500000,2);
i=gun;
j=stoi(3);
k=gadd(i,j);
printf("1+3=%s\n",GENtostr(k));
return 0;
}
It looks like you're using code intended for a very old version of PARI. Modern versions use gen_1 rather than gun for the constant 1. With this change,
gcc -o test-pari test-pari.c -lpari && ./test-pari
yields
1+3=4
as desired. Alternatively (not recommended!), if you're trying to port a lot of old code, you could add
#define PARI_OLD_NAMES
before
#include <pari/pari.h>
and the code with work with gun.
all.
Compiling simple stuff using the gcc toolchain for several years, today I ran against a curious phenomenon.
I installed Kubuntu 14.04 to a common desktop i686 machine with gcc 4.8.2 in it. But then, trying to build some well coded stuff pulled out from my local repository, I ran against tons of 'undefined reference to' messages. The code compiles, links und runs well under Ubuntu 11.04 / gcc 4.5.2.
I checked the linking process (by -Wl,--verbose to gcc), think it works. It finds all libraries I specify in the link command. An objdump -t myLib.so brings exactly the symbols I'd expect - but the linker doesn't see them.
Checking the pthread library also brings according symbols, except they are suffixed with some #GLIBC... stuff. Didn't check linker/loader tricks so far.
A sample like
#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
static void *fooo (void *xxx) {
char *txt = (char*)xxx;
printf("My job is to print this :'%s'. Bye now!\n", txt);
return 0;
}
int main (int argc, char *argv[]) {
pthread_t thd;
pthread_create(&thd, NULL, fooo, "A POSIX thread");
sleep(1);
return 0;
}
runs very well on the old system just saying
gcc -l pthread fooo.c && ./a.out
but breaks at the linking step with 4.8.2.
Any idea would be very welcome.
.M
Thanks to sfrehse, JoachimPileborg et al!
Indeed, success depends on argument order. I knew this fact for static linking, but it is new in processing of shared objects with gcc.
Does someone know what the background of this improvement is? It breaks innumerable build processes, and I guess thousands of tomatoes are being made ready against gcc.gnu.org .....
.M
After I declared a variable in this way:
#include <thread>
namespace thread_space
{
thread_local int s;
} //etc.
i tried to compile my code using 'g++ -std=c++0x -pthread [sourcefile]'. I get the following error:
example.C:6:8: error: thread-local storage is unsupported for the current target
static thread_local int s;
^
1 error generated.
If i try to compile the same code on Linux with GCC 4.8.1 whit the same flags, i get a functioning executable file. I'm using clang-503.0.40 (the one which comes with Xcode 5.1.1) on a MacBook Pro running OSX 10.9.3. Can anybody explain me what i'm doing wrong?
Thank you!!
Try clang++ -stdlib=libc++ -std=c++11. OS X's outdated libstdc++ doesn't support TLS.
Edit
Ok, this works for the normal clang version but not for the Xcode one.
I did a diff against Apple's clang (503.0.38) and the normal released one and found the following difference:
.Case("cxx_thread_local",
- LangOpts.CPlusPlus11 && PP.getTargetInfo().isTLSSupported() &&
- !PP.getTargetInfo().getTriple().isOSDarwin())
+ LangOpts.CPlusPlus11 && PP.getTargetInfo().isTLSSupported())
So I think this is a bug in Apple's clang version (or they kept it in there on purpose - but still weird, because -v says based on 3.4).
Alternatively, you can use compiler extensions such as __thread (GCC/Clang) or __declspec(thread) (Visual Studio).
Wrap it in a macro and you can easily port your code across different compilers and language versions:
#if HAS_CXX11_THREAD_LOCAL
#define ATTRIBUTE_TLS thread_local
#elif defined (__GNUC__)
#define ATTRIBUTE_TLS __thread
#elif defined (_MSC_VER)
#define ATTRIBUTE_TLS __declspec(thread)
#else // !C++11 && !__GNUC__ && !_MSC_VER
#error "Define a thread local storage qualifier for your compiler/platform!"
#endif
...
ATTRIBUTE_TLS static unsigned int tls_int;
The clang compiler included in the Xcode 8 Beta and GM releases supports the C++11 thread_local keyword with both -std=c++11 and -std=c++14 (as well as the GCC variants).
Earlier versions of Xcode apparently supported C-style thread local storage using the keywords __thread or _Thread_local, according to the WWDC 2016 video "What's New in LLVM" (see the discussion beginning at 5:50).
Seems like you might need to set the minimum OS X version you target to 10.7 or higher.
I have:
-cygwin 1.7.25 on windows 7/32bit
-g++ --version --> g++ (GCC) 4.8.2
-libstdc++.a --> gcc-g++-4.8.2-1
Tried to make a c++
Hello World:
#include <string>
int main()
{
std::string s = "123";
int i = std::stoi(s);
}
compiling gives:
$ g++ -std=c++11 main.cpp
main.cpp: In function ‘int main()’:
main.cpp:6:10: error: ‘stoi’ is not a member of ‘std’
int i = std::stoi(s);
I searched for hours but I still could not find a solution. What's the issue here?
That's a bug, possibly an incomplete port of some library code to cygwin (it's a cplusplus11 feature) - some stuff has to be changed after all. Make sure to report it.
The solution is easy of course: #include <cstdlib> strtol(s.c_str(),0,10);
www.cplusplus.com/.../strtol
A similar mingw bug is mentioned also here
std::stoi doesn't exist in g++ 4.6.1 on MinGW
I have the same problem yesterday. "error: 'stoi' is not a member of 'std'."
First, I made sure c++11 was enabled. Then, I updated the g++ compiler to the newest version. After that, this error disappeared.
The compiler is not being taken seriously. On windows your best bet is to probably use visual studio, as it is always kept up to date . The bug here is that the macro defs are wrong to begin with. The problem starts from iomanip.h and iosbase . So they would have to changed all of there code. There are user made patches for this but I would not trust them at all, as they may contain even more bugs then the original copies. But it's up to you , I just stick with visual studio express edition.
stoi works correct only on mingw64 for me.
If you use Codeblocks, don't forget to check if your projects compiler is set to mingw64.
Well, I am working with -std=c++98, not -std=c++11 but I solved it with the following:
int i = std::atoi(input.c_str());
atoi() is waiting for c type null-terminated string, c_str() makes it null-terminated char*. To use atoi I also() added the following library:
#include <cstdlib>
my system is:
Ubuntu 22.04.1 LTS
I have an example code:
#include <quadmath.h>
int main()
{
__float128 foo=123;
cosq(foo);
return 0;
}
I tried to compile it with the following commands:
g++ f128.cpp -lquadmath
g++ f128.cpp /usr/lib64/gcc/x86_64-suse-linux/4.6/libquadmath.a
g++ f128.cpp /usr/lib64/gcc/x86_64-suse-linux/4.6/libquadmath.a /usr/lib64/libquadmath.so.0
g++ f128.cpp /usr/lib64/gcc/x86_64-suse-linux/4.6/libquadmath.a /usr/lib64/libquadmath.so.0 /usr/lib64/gcc/x86_64-suse-linux/4.6/libquadmath.a
All these commands produce one and the same error:
f128.cpp:(.text+0x1b): undefined reference to `cosq(__float128)'
I also tried to declare cosq as follows, without inluding quadmath.h. Declarations of such style are used in C++ interface to fortran subroutines in other programs, and they work well.
extern "C" __float128 cosq_(__float128 *op);
extern "C" __float128 cosq_(__float128 op);
extern "C" __float128 cosq(__float128 *op);
...and so on...
Result was the same.
Then I tried to use cosq in Fortran:
PROGRAM test
REAL*16 foo
REAL*16 res
foo=1;
res=cos(foo)
PRINT *,res
END
This program compiles and executes well (prints the answer with lots of digits), so cosq works in it. This program was compiled with no options: gfortran f128.f90.
OS is OpenSUSE 12.1, gcc version is 4.6.2. *.h, *.a and *.so files mentioned are provided by gcc46-fortran and libquadmath46 packages.
What is the proper way to use cosq and other quadmath functions in C++? I wouldn't like to write Fortran wrappers for them.
First, according to Nikos C. advise, I boot up OpenSUSE 12.2 liveCD (which has gcc 4.7.1) on another machine, but got the same error.
Then I posted this question to OpenSUSE forums.
Martin_helm's answer shows that the problem is distro-independent and the solution is trivial:
extern "C" {
#include <quadmath.h>
}
This works fine on all my machines. Program can be compiled with g++ prog.cpp -lquadmath.