I am currently running the latest version of Code-blocks in Ubuntu 11.04.
I have GTK+2, and 3 developer libraries fully installed (and working), and presumably have x11 installed. The header files are there.
However, a simple code will not compile using x11 coding.
#include "X11/Xlib.h"
int main() {
Display *display = XOpenDisplay(0);
Window root = DefaultRootWindow(display);
XWarpPointer(display, None, root, 0, 0, 0, 0, 100, 100);
XCloseDisplay(display);
return 0;
}
This give me the readout of:
obj/Release/main.o||In function `main':|
undefined reference to `XOpenDisplay'
undefined reference to `XWarpPointer'
undefined reference to `XCloseDisplay'
|=== Build finished: 3 errors, 0 warnings ===|
I've tried reading multiple webpages of 'linking' x11, I only find headerfiles, and not the file type asked by the linker within the compiler (That's the wrong term for that.. it's not a compiler.. it's something else.. I know. Apologies)
I don't know what Code Blocks is, but for a normal compile/link process, you need to specify -lX11 to link with libX11.so for the Xlib functions.
Thanks! I just had the same problem. To spell it out:
Settings > Compiler and Debugger > Linker settings > Other linker options > "-lX11"
For the record 'codelite' got it right all by itself.
In CodeBlocks you can just set in the project options libraries to link against, setting -lX11 in the compiler settings will make every program you compile with codeblocks link against X11.
Related
How to force CMake to use a response file when linking CUDA on Windows?
I have been trying to create a convenience library on Windows in a
project that has CUDA. The goal is to wrap up several libraries into
one. The first approach was the straightforward
add_library(conv
$<TARGET_OBJECTS:a>
$<TARGET_OBJECTS:b>
$<TARGET_OBJECTS:c>
)
which tries to link with nvcc, but overruns the windows command line length limit. I.e, it emits
The command line is too long.
There are no problems on Darwin or Linux.
Then I discovered in cmake-3.20.3 the code,
NVIDIA-CUDA.cmake: set(CMAKE_CUDA_RESPONSE_FILE_FLAG "--options-file ")
which led me to wonder whether I could just override the defaults by
setting
set(CMAKE_CUDA_USE_RESPONSE_FILE_FOR_LIBRARIES TRUE)
but upon doing so, I saw no change in behavior. It still links with nvcc, it still does not use a response file, and it still results in command line too long.
So then I tried setting the linker to be the Windows linker with
set_property(TARGET conv PROPERTY LINKER_LANGUAGE CXX)
and making sure to have
-- CMAKE_CXX_USE_RESPONSE_FILE_FOR_LIBRARIES= TRUE
But the linker remained nvcc, and no response file was used.
Any ideas on how to fix this?
Looks like the option to use a response or options file in CUDA is not yet available in CMake. In current master (line 129):
# FIXME: investigate use of --options-file.
# Tell Makefile generator that nvcc does not support #<rspfile> syntax.
set(CMAKE_CUDA_USE_RESPONSE_FILE_FOR_INCLUDES 0)
set(CMAKE_CUDA_USE_RESPONSE_FILE_FOR_LIBRARIES 0)
set(CMAKE_CUDA_USE_RESPONSE_FILE_FOR_OBJECTS 0)
I had compiled a simple hello world program in C with the MinGW compiler using the command line. As it had finished compiling, windows defender popped up and detected a virus (Trojan:Win32/Fuery.C!cl).
#include <stdio.h>
#include <stdlib.h>
int main() {
printf("Hello World");
return 0;
}
https://imgur.com/a/05yDjw5
I had taken action on this (Removed) as windows defender suggested, but when I compile again the same happened, multiple times.
I had downloaded an AntiVirus (Malwarebytes) and scanned my whole system and it detected some registry key errors, but not this.
I've tried compiling C++ files too, but windows defender did not detect any virus there. This only happens when I compile in C.
I've also tried checking the compiled executable at VirusTotal.
https://www.virustotal.com/gui/file/476d47215dad80db49c9fd508ab5e10e5aeb5b623248ca156830a28b70affe5f/detection
I tried CodeBlock's MinGW compiler and 0 engines detected it. (Same C file)
https://www.virustotal.com/gui/file/8ba4b0fa24b1b6b69152acce2353fcca8447bbecbfc4e5ec48d33cc75d94f2f1/detection
EDIT: I deleted the path variable of C:/MinGW and added CodeBlock's MinGW compiler. I then used the command line to compile the same C file again and had uploaded the .exe file to VirusTotal. This time, 0 engines detected. So I have come to the conclusion that, the MinGW compiler that I had installed was creating this problem.
https://www.virustotal.com/gui/file/34d383f6c09f897d8c9a44ed0e7850574320e50fdf439eeb1f06705fdcc95386/detection
I don't know why this happens. Is there a malware in my computer that affects my C programs or is this a false detection?
There is no malware, it is a false positive. The executable generated by your version of MinGW looks very similar to a particular virus.
To avoid the problem, add the directory where you build your code to the list of exclusion in the antivirus.
Also consider using mingw-w64 instead of mingw.org .
I came across with the same problem, compiler tdm gcc v9.2.
The following compilation triggers a warning (kaspersky).
gcc temp.c -o temp.exe
The following does not
gcc -O3 temp.c -o temp.exe
Where temp.c is
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
int main() {
int a, b;
scanf("%d %d", &a, &b);
printf("mod %4d, %4d is %4d\n", a, b, a%b);
return 0;
}
The same code with g++ passes the test with both compilations. The antivirus software does not detect the same virus elsewhere but only in temp.exe (first compilation).
I may have solved my problem.
This is what I did: I removed the PATH Variable of C:\MinGW and added CodeBlock's MinGW compiler (CodeBlocks/MinGW/bin). I used the command line to compile the same C file, and had uploaded the .exe to VirusTotal. No engines detected this file!
https://www.virustotal.com/gui/file/34d383f6c09f897d8c9a44ed0e7850574320e50fdf439eeb1f06705fdcc95386/detection
So I have come to a conclusion that, MinGW was the compiler that was causing this problem. I have removed it.
However, I am not quite sure if this problem is FULLY solved. There is still a possibility of malware affecting my executable (or perhaps not). I cannot be sure.
If anyone has any answers, please comment or answer
I ran into this after installing MinGW on 01-08-20(dd-mm-yy).
For me it was also Windows Defender, the way to - hopefully temporarily- get rid of this is to add an exception for the folder your compilation output will reside in.
The Microsoft website states these steps to add an exclusion:
Go to Start > Settings > Update & Security > Windows Security > Virus & threat protection.
Under Virus & threat protection settings, select Manage settings, and then under Exclusions, select Add or remove exclusions
I had a similar problem. I figured out that the following dll was missing: mingw32-libmingwex-dll. Once I installed it via "MinGW Installation Package", I didn't have the problem anymore.
I hope this can help others.
Since you wrote that program and you know it isn't actually a Trojan, it's obviously a false positive. You should submit the file to them at https://www.microsoft.com/wdsi/filesubmission so they can figure out why it's triggering the false positive and fix it. (If it happens with everything you compile, just sending them one will suffice.) In the meantime, you should add an exclusion to Windows Defender for the folder that you compile your executables in.
I'm trying to compile a simple Boost Wave example and while Xcode is recognizing the headers, it is giving me a slew of Apple Mach-O Linker(Id) Errors. I have encountered this before and I don't remember how I solved it. Please help!
I have attached a screenshot.
P.S. I have Boost 1.57.0 and it works just fine with any Xcode Project. For whatever reason, though, it isn't in the case when it involves the header boost/wave.hpp like so...
#include <boost/wave.hpp>
Also, I ruled out the body of the code as a culprit. This throws the linker erros:
#include <boost/wave.hpp>
int main() { return 0; }
Other Boost headers like these, do not:
#include <boost/function.hpp>
int main() { return 0; }
I figured it out, but have no idea why this is the case. If anyone would like to add an explanation, that would be splendid. I had to manually add the various dynamic and static libraries referenced in each of the above issues. I attached a new screenshot so others having this issue can see the end result.
Well, the explanation is very simple. In order to be able to build your project, the compiler working under the hood needs to know:
Where to search for the #include <..> within your project's files: this corresponds to the -I directory option for the g++ compiler. In Xcode this corresponds to set the "Header Search Paths" in the Build Settings of you project.
Without specifying the Header Search Paths, you will get errors on the #include lines since Xcode doesn't know where to look for those included files.
Where to search for the library that must be linked to your source code while building the project: this corresponds to the -L directory option for the g++ compiler. In Xcode this corresponds to set the "Library Search Paths" in the Build Settings of you project.
Without specifying the ** Library Search Paths**, you will get errors while trying to build your project since Xcode doesn't know where to look for the linked libraries.
What libraries must be linked to your project files at compilation time: this corresponds to the -l linking option for the g++ compiler.
In Xcode this corresponds to add the .dylib files to the Link Binary With Libraries in the Build Phases settings of your project. Note that you don't need to add manually the libraries to the main folder of your project, the last described step suffice.
See here and here for the directory and linking options of the g++ compiler, respectively.
OK, so I have been following this tutorial.
I set up everything as told (double checked everything), only thing I changed is (step 10), from
${OGRE_HOME}\boost_1_44
to
${OGRE_HOME}\boost
since in my Ogre SDK version (1.81), there is no boost_1_44 folder, only boost folder.
Anyhow, as I said, when I try to compile my program, I get this three errors :
undefined reference to boost::system::generic_category()
undefined reference to boost::system::generic_category()
undefined reference to boost::system::system_category()
I have tried adding this : -lboost_system to my Project. I went to Properties > C/C++ Build > Settings > GCC C++ Compiler > Miscellaneous and added it to the existing flags, but no luck.
I googled, and apparently that is the only solution possible. So, I ask you, if someone could explain me (as simple as possible please, step by step) how to fix this compiler errors.
EDIT : I'm using MinGW as a compiler (I use it with MSYS).
I have had similar problems compiling in linux using CMake and clang. I fixed it by adding the flag
-DBOOST_SYSTEM_NO_DEPRECATED
This "comments" out the lines causing the problem. I don't know if this will fix your errors but it did fix mine.
(If you use ./configure also add CPPFLAGS='-DBOOST_SYSTEM_NO_DEPRECATED' as a parameter).
I wanted to move my own gtk program from old MinGW to the latest one. I met a lot of questions in the past 2 weeks and couldn't find a way. Please refer to the other 2 questions I posted:
does mingw influence compilation a gtk program and compile gtk in mingw but failed.
Finally, I compiled gtk+2.24.10 by myself in MinGW. Followed are the details for environment:
GTK version gcc version
old mingw 2.10.11 -- from third party 3.4.5
new mingw 2.24.10 -- compiled by myself 4.7.2 or 4.6.2 -- I tried both
For the program in the old environment, everything runs well.
For the program in the new environment, the problem mentioned above "does mingw influence compilation a gtk program" disappeared. But there is a new problem I can't find any clue where it comes from:
When launching my program, if I move the GUI window, it crashed. I used gdb to debug, but if it crashed, system is frozen. The only way is to use "ctrl + alt + del" to activate task manager and stop the program. Then in GDB, where or bt full didn't show any useful information. If I don't move the GUI window, all the function in the window runs well. One more thing, my program uses openssl and pdflib which are from third party. The program links to the libs, but they are not used when the GUI window just is launched.
Is any bug in my own code? I don't think so because it runs well in the old MinGW environment. Some warnings about g_thread_create, g_thread_init is deprecated are in gtk+2.24.10 packages but don't show up in gtk+2.10.11 packages.
Is anything wrong with the gtk system, including gtk, glib, cario, atk etc., compiled by myself in MinGW? I can't tell. But gtk_demo included in gtk package runs well, I can move the program's window to wherever.
Is it related with gcc version? I can't tell. I googled and found someone complained that his gtk program complied by gcc 4.7.x is not stable and is affected by many sudden crashes. gcc 4.6.2 is absolutely suggested by someone. But in my case, it still crashed even compiled by gcc 4.6.2.
Is it related with openssl and pdflib which are from third party due to ABI issue? I can't tell.
M code is compiled in a Linux environment -- gtk+2.24.6. It does run well.
UPDATE 1:
I found some clue. The problem is from thread. But I still didn't know why it worked in the old MinGW but failed in the new MinGW. Followed is a simple example.
As I said, if I compile it in old MinGW, it worked -- the data, in fact a counter, is updated in the widget. And I can move the window.
If I compile it in new MinGW, it worked -- the data, in fact a counter, is updated in the widget. But if I move the window, it crashed. If I commented what are related with thread, then I can move the window, but data won't be updated in the window.
#include <gtk/gtk.h>
static int counter = 0;
static PangoLayout* layout;
static GdkGC* gc1;
static GdkGC* gc2;
//**/static GMutex* mu;
static gboolean on_expose_event(GtkWidget* widget, GdkEventExpose* event)
{
gchar the_string[20];
//**/g_mutex_lock(mu);
gdk_draw_rectangle(GDK_DRAWABLE(widget->window), gc1, TRUE, 0, 0, widget->allocation.width, widget->allocation.height);
snprintf(the_string, 20, "%d", counter);
pango_layout_set_text(layout, the_string, -1);
gdk_draw_layout(GDK_DRAWABLE(widget->window), gc2, 180, 120, layout);
//**/g_mutex_unlock(mu);
g_print (".");
return FALSE;
}
gpointer func(gpointer data)
{
//**/g_usleep(10000);
GdkWindow* window = GDK_WINDOW(data);
while(TRUE)
{
gdk_threads_enter();
gdk_window_invalidate_rect(window, NULL, FALSE);
gdk_threads_leave();
//**/gdk_window_process_updates(window, FALSE);
if(counter % 100 == 0) g_print("X");
g_usleep(10);
++counter;
}
return FALSE;
}
int main(int argc, char** argv)
{
GtkWidget* window;
GtkWidget* drawer;
GdkColormap* colormap;
GdkColor color;
g_thread_init(NULL);
gdk_threads_init();
gtk_init(&argc, &argv);
//:Create widgets and
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
drawer = gtk_drawing_area_new();
gtk_widget_set_size_request(drawer, 400, 300);
gtk_container_add(GTK_CONTAINER(window), drawer);
//.
gtk_widget_show_all(window);
//:Initializing Graphic Contexts
colormap = gtk_widget_get_colormap(GTK_WIDGET(drawer));
layout = gtk_widget_create_pango_layout(GTK_WIDGET(drawer), NULL);
gc1 = gdk_gc_new(GDK_DRAWABLE(GTK_WIDGET(drawer)->window));
gc2 = gdk_gc_new(GDK_DRAWABLE(GTK_WIDGET(drawer)->window));
gdk_color_parse("#000", &color);
gdk_colormap_alloc_color(colormap, &color, FALSE, TRUE);
gdk_gc_set_background(gc1, &color);
gdk_color_parse("#fff", &color);
gdk_colormap_alloc_color(colormap, &color, FALSE, TRUE);
gdk_gc_set_foreground(gc2, &color);
//.
g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(gtk_main_quit), NULL);
g_signal_connect(G_OBJECT(drawer), "expose_event", G_CALLBACK(on_expose_event), NULL);
//**/mu = g_mutex_new();
//Run the problematic thread!
g_thread_create(func, GTK_WIDGET(drawer)->window, FALSE, NULL);
gdk_threads_enter();
gtk_main();
gdk_threads_leave();
//**/g_mutex_free(mu);
return 0;
}
Compile:
gcc -g -o example update_widget.c `pkg-config --libs --cflags gtk+-2.0 gthread-2.0`
UPDATE 2:
I checked config.log of compilation of glib and found the words below:
configure:26678: WARNING: I can't find the MACRO to enable thread safety on your
platform (normally it's _REENTRANT). I'll not use any flag on
compilation now, but then your programs might not work.
Please provide information on how it is done on your system.
Does it influence the thread function?
My configure for compilation of glib is:
export CFLAGS="-march=i686"
./configure --prefix=$HOME/gtk+$GTK_VERSION --with-threads=win32 --with-pcre=internal
make
make install