This is puzzling me...
I have a code that looks like this:
#include <stdio.h>
#include <pbs_ifl.h>
int doSomeStuff()
{
char *server_name;
int c;
server_name = pbs_default();
c = pbs_connect(server_name);
printf("pbs_errno %d\n",pbs_errno);
// do some stuff
pbs_disconnect(c);
}
When I compile it with:
gcc -static -o executablename sourcefile.c -ltorque
It works allright, compiling with '-static'. pbs_errno is 0 and I can do my stuff.
But if I remove the '-static' flag it starts giving me this message when I run it:
munge: Error: Unable to access "/var/run/munge/munge.socket.2": No such file or directory
So... I start the munge service (munged) and it stops complaining about it, but instead I get pbs_errno=15033 and can't get anything from the cluster (do my stuff).
Any ideas?
I don't know if I delete de question or answer it, but it seems so be solved... so I'm posting the solution here.
I had 2 versions of the lib installed, one via yum other via source.
Since only the compiled code had the static libs, when I was linking -static gcc was linking with the compiled code and when I was linking dynamic it was linking with the yum version.
I just had to enforce the linking with the right libs adding the following flag when liking:
-Wl,-rpath=/usr/local/lib
Related
Recently I tried to create tool using Windows Update Agent API in C++.
The problem is, even include of the wuapi.h header file causes problems on my machine.
It keeps saying, the header file could not be found.
#include <wuapi.h>
int main(int argc, char **args)
{
return 0;
}
Attempt to compile the simple code ends up predictably:
gcc -o tool.exe file.cpp -pedantic -Wall -Wextra
file.cpp:1:10: fatal error: wuapi.h: No such file or directory
#include <wuapi.h>
^~~~~~~~~
compilation terminated.
I found almost no information related to this issue on the Internet so far. That means I'm not sure what's wrong at all.
I'm using Windows 10.0.18362.592 but more importantly I'm using mingw-w64 8.1.0 as a compiler.
At this point I'm not sure, whether mingw-w64 supports this part of Win32 API. I found no useful information though.
I'm really a Python developer exclusively, but I'm making my first foray into C programming now, and I'm having a lot of trouble getting started. I can't seem to get the hang of compilation and including libraries. At this point, I'm just identifying the libraries that I need and trying to compile them with a basic "hello, world" app just to make sure that I have my environment setup to do the actual programming.
This is a DBus backend application that will use GIO to connect to DBus.
#include <stdlib.h>
#include <gio/gio.h>
int
main (int argc, char *argv[])
{
printf("hello, world");
return 0;
}
Then, I try to compile:
~$ gcc main.c
main.c:2:21: fatal error: gio/gio.h: No such file or directory
#include <gio/gio.h>
I believe that I've installed the correct packages as indicated here, and gio.h exists at /usr/include/glib-2.0/gio/gio.h.
I found a command online to add a search directory to gcc, but that resulted in other errors:
~$ gcc -I /usr/include/glib-2.0/ main.c
In file included from /usr/include/glib-2.0/glib/galloca.h:34:0,
from /usr/include/glib-2.0/glib.h:32,
from /usr/include/glib-2.0/gobject/gbinding.h:30,
from /usr/include/glib-2.0/glib-object.h:25,
from /usr/include/glib-2.0/gio/gioenums.h:30,
from /usr/include/glib-2.0/gio/giotypes.h:30,
from /usr/include/glib-2.0/gio/gio.h:28,
from main.c:2:
/usr/include/glib-2.0/glib/gtypes.h:34:24: fatal error: glibconfig.h: No such file or directory
#include <glibconfig.h>
^
compilation terminated.
There has to be some relatively simple method for being able to set some options/variables (makefile?) to automatically include the necessary headers. I'm also going to use Eclipse-CDT or Anjuta as an IDE and would appreciate help to fix the import path (or whatever it's called in C).
Any help is greatly appreciated.
Use pkg-config (and make). See exactly this answer to a very similar question. See also this and that answers. Don't forget -Wall -g flags to gcc ..
You don't need an IDE to compile your code (the IDE will just run some gcc commands, so better know how to use them yourself).
I am porting some code to OpenBSD 5.0 and I ran into this very strange problem.
My build settings use -isystem /usr/local/include. It is hard to remember but I believe I did that to avoid masses of compiler warnings from my use of -Wall on system types -- like BSD -- that install Boost to /usr/local/include. This seems to work great on FreeBSD.
So take the following program:
#include <boost/array.hpp>
int main()
{
return 0;
}
Then build it with:
c++ -O2 -pipe -isystem /usr/local/include -std=c++98 -o test test.cxx
On OpenBSD I discovered that I get:
In file included from /usr/include/g++/string:46,
from /usr/include/g++/stdexcept:44,
from /usr/local/include/boost/array.hpp:35,
from test.cxx:1:
/usr/include/g++/bits/stringfwd.h:48: error: template with C linkage
And it only gets worse from there.
I discovered that I can change the error messages by doing things such as:
#include <stdexcept>
But that only pushes the problem farther back. It is as if the compiler is wrapping every include file inside an extern "C" block.
So far, the only working method seems to be to change back to using -I /usr/local/include and accept the noise from -Wall -W.
The question is, why did OpenBSD do this? It has to be some kind of custom hack to GCC to treat system includes this way.
Recently came across the same issue when working with a freestanding cross compiler.
It seems G++ will do this when targeting "old" systems as indicated here:
http://tigcc.ticalc.org/doc/cpp.html#SEC9a
On very old systems, some of the pre-defined system header directories get even more special treatment. GNU C++ considers code in headers found in those directories to be surrounded by an extern "C" block. There is no way to request this behavior with a #pragma, or from the command line.
Hope this may provide some insight to future travelers here.
On an almost default install of Ubuntu 11.04 I installed clang.
I am trying to compile this:
#include <cstdlib>
int main(){
return 0;
}
g++ can deal with it just fine, but clang++ errors out: fatal error: 'cstdlib' file not found
Can someone explain why this happens? and what needs to be done to make this work?
I expected clang++ to be a drop-on replacement for g++.
Seems like your clang build is not searching the correct platform include paths. Try checking with
clang -v ...
where it is looking for headers (and check that your platform include paths are there). You might have to add additional include directories (e.g. /usr/include/c++/x.y).
You might want to take a look at the source file lib/Frontend/InitHeaderSearch.cpp, The method AddDefaultCPlusPlusIncludePaths does some distribution/gcc-version specific magic (I had to fix it for my own system once).
I want to static link libray which I included (such as stdio) with gcc, so I use the -static options.
My environment is ubuntu 10.10.
gcc version is 4.4.5.
the compile command I used is : gcc -static -o output.out input.c
the following is my source code.
include
int main(){
printf("hello world");
return 0;
}
After I compile it and use the -static option, I objdump the executable file.
and I found out that the printf is actually called _IO_printf.
And I write another program, the following is the souce code.
include
int main(){
return 0;
}
I compile this source code with the same option and objdump the new executable file.
However, I can't find the _IO_printf.
My question is why I can't fine _IO_printf in the second case. I have static linked the libray which I included.
Can someone plz help me solve this problem, thx.
A linker doesn't just put object files and libraries together. It creates links between the different parts. So if there is an unresolved symbol (e.g. function or variable) in one unit, it looks for it in other units and makes the connection.
Since the second program doesn't call printf, the linker does not need to resolve that symbol. So there is no point adding that function to the executable (it'll just sit there and take space). The linker can see what's missing, and should (normally) add only what's missing down to some practical granularity.