__block on Windows in order to compile libdispatch - visual-c++

I am trying to compile (parts of) libdispatch, a.k.a. <dispatch/dispatch.h> on Windows. I tried with MSVC v140, but since the Microsoft compiler doesn't support Blocks, I guess I'm out of luck with MSVC. My plan is to compile with Clang, which integrates into Visual Studio thanks to those LLVM Snapshot Builds: http://llvm.org/builds/
Trying to compile the blocks example from Wikipedia with that Clang for VS compiler
typedef int (^IntBlock)();
IntBlock MakeCounter(int start, int increment) {
__block int i = start;
return Block_copy( ^ {
int ret = i;
i += increment;
return ret;
});
}
fails with the error message:
'__block' undeclared identifier
What's the problem here? I thought, Clang would support blocks?
What can I do to get this to compile?

Have you tried to specify the compiler flag -fblocks?
$ clang a.c -fblocks
I don't know the default settings of Clang Windows binary, but on OS X (the default is -fblocks), with -fno-blocks got the same error.
$ clang -v
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.5.0
Thread model: posix
$ clang a.c -fno-blocks
a.c:3:5: error: use of undeclared identifier '__block'

Related

Pytorch Tensor::data_ptr<long long>() not working on Linux

I cannot link my program to pytorch under Linux, get the following error:
/tmp/ccbgkLx2.o: In function `long long* at::Tensor::data<long long>() const':
test.cpp:(.text._ZNK2at6Tensor4dataIxEEPT_v[_ZNK2at6Tensor4dataIxEEPT_v]+0x14): undefined reference to `long long* at::Tensor::data_ptr<long long>() const'
I am building a very simple minimal example:
#include "torch/script.h"
#include <iostream>
int main() {
auto options = torch::TensorOptions().dtype(torch::kInt64);
torch::NoGradGuard no_grad;
auto T = torch::zeros(20, options).view({ 10, 2 });
long long *data = (long long *)T.data<long long>();
data[0] = 1;
return 0;
}
The command used to build it:
g++ -w -std=c++17 -o test-torch test.cpp -D_GLIBCXX_USE_CXX11_ABI=1 -Wl,--whole-archive -ldl -lpthread -Wl,--no-whole-archive -I../libtorch/include -L../libtorch/lib -ltorch -ltorch_cpu -lc10 -Wl,-rpath,../libtorch/lib
Pytorch has been downloaded from the link https://download.pytorch.org/libtorch/cpu/libtorch-cxx11-abi-shared-with-deps-1.7.0%2Bcpu.zip and unzipped (so I have the libtorch folder next to the folder with test.cpp).
Any ideas how to solve this problem? Same program works just fine under Visual C++.
P.S. I know pytorch is kind of designed for cmake, but I have zero experience with cmake and no desire to write a cmake-based build system for my app. Also, the examples they give are seemingly supposed to only work if pytorch is "installed" in the system. So I cannot just download the .zip with libs? And if I "install" it (e.g. from sources or in whatever other way) on an AVX512 system, will the binary I link to it and distribute to end-users work on non-AVX512? The documentation is completely incomprehensible for newbies.
UPDATE: I tried to do this via CMake following the tutorial https://pytorch.org/cppdocs/installing.html and got exactly the same error. Specifically, I renamed my directory to example-app and the source file to example-app.cpp. Then I created CMakeLists.txt in this directory with the following contents:
cmake_minimum_required(VERSION 3.0 FATAL_ERROR)
project(example-app)
find_package(Torch REQUIRED)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${TORCH_CXX_FLAGS}")
add_executable(example-app example-app.cpp)
target_link_libraries(example-app "${TORCH_LIBRARIES}")
set_property(TARGET example-app PROPERTY CXX_STANDARD 14)
Then
mkdir build
cd build
cmake -DCMAKE_PREFIX_PATH=../../libtorch ..
cmake --build . --config Release
And here's the output:
CMakeFiles/example-app.dir/example-app.cpp.o: In function `long long* at::Tensor::data<long long>() const':
example-app.cpp:(.text._ZNK2at6Tensor4dataIxEEPT_v[_ZNK2at6Tensor4dataIxEEPT_v]+0x14): undefined reference to `long long* at::Tensor::data_ptr<long long>() const'
Makes me think, maybe I forgot to include some header or define some variable?
Oh, this is all on Mint 19.2 (equivalent to Ubuntu 18.04), g++ version is 7.5.0, glibc is 2.27. Compiling with g++-8 gives the same result.
This is not a cmake-related error, it's just how the library was implemented. I do not know why, but it appears that the specialization of T* at::Tensor::data<T> const with T = long long was forgotten/omitted.
If you want to get your signed 64-bits pointer, you can still get it with int64_t:
auto data = T.data<int64_t>();
It's good practice to use these types for which the size is explicit in general, in order to avoid compatibility issues.

Asio C++11 Thread Exception: The attempted operation is not supported for the type of object referenced

I'm trying to write a HTTPS client connection to iOS and Android using C++11 Asio's header only library (without boost),
and I'm testing the c++ code on Windows 10. (I tested on Windows 8 too, but the problem is the same)
I got an exception, so I write a simple example myself to find out what's happening. This is the code:
#include <iostream>
#include "asio.hpp"
void hello_world_thread() {
std::cout << "Hello world!" << std::endl;
}
int main()
{
asio::thread t(
std::bind(
&hello_world_thread
)
);
t.join();
return 0;
}
And if I run this inside / outside Code::Blocks I got the following exception:
terminate called after throwing an instance of 'std::system_error'
what(): thread: The attempted operation is not supported for the type
of object referenced.
This application has requested the Runtime to terminate it in an
unusual way. Please contact the application's support team for more
information.
The build command is:
x86_64-w64-mingw32-g++.exe -std=c++11 -Wall
-DASIO_STANDALONE -g -Iasio -c D:\Projektek\C++\AsioTeszt\main.cpp -o obj\Debug\main.o
x86_64-w64-mingw32-g++.exe -o bin\Debug\AsioTeszt.exe
obj\Debug\main.o -lws2_32 -static -static-libgcc -static-libstdc++ -m64
I had already tried the -pthread flag, but the error is the same.
MinGW version: gcc version 5.1.0 (x86_64-win32-seh-rev0, Built by MinGW-W64 project)
Asio version: 1.10.6 (And tried with the Dev release too 1.11.0)
Finally I figured out after 3 days of suffering.
The problem was with the MinGW installation, because I selected win32 at the Threads section.
After reinstallation with posix threads selected everything works fine.
Edit: I again run into this problem but I used the Asio thread in another project. So I started remove everything until I had found out what was missing.
#include <map>
Without this it won't work.

Building TIC fails (ncurses5.9) for CLFS 3.0.0 SYSTEMD

Recently I decided to retry building a CLFS machine http://www.clfs.org and am at step 5.5 of 3.0.0 SYSTEMD. We are told to run make -C include and then make -C progs tic. I am failing at the last command. Am I missing any packages, or am I doing something wrong?
I am using ArchLinux as my CLFS host in VMWare which is running on Windows 10.
Here is the page I am looking at for the commands: http://clfs.org/files/BOOK/3.0.0/SYSTEMD/view/x86_64/cross-tools/ncurses.html
Here is the output from the console when I run that last command:
In file included from ../ncurses/curses.priv.h:283:0,
from ../ncurses/lib_gen.c:19:_33528.c:835:15: error: expected ')' before 'int'
../include/curses.h:1594:56: note: in definition of macro 'mouse_trafo'
#define mouse_trafo(y,x,to_screen) wmouse_trafo(stdscr,y,x,to_screen)
^
The error message is pointing to the y symbol,
which could be (mis)defined in some header file on your system.
aside from stray #define's, the only interesting thing about the line is that the prototype for wmouse_trafo uses bool, which the configure script should have (given the compiler version used for CLFS) equated to a c99 _Bool (which should not be a problem).
You can see what the compiler sees by doing
make -C ncurses lib_gen.i
and looking for wmouse_trafo in ncurses/lib_gen.i.
For example, I see it mentioned twice:
extern _Bool wmouse_trafo (const WINDOW*, int*, int*, _Bool);
extern _Bool mouse_trafo (int*, int*, _Bool);
and
_Bool (mouse_trafo) (int * a1, int * a2, _Bool z)
{
; return wmouse_trafo(stdscr,a1,a2,z);
}
The stray semicolon is not a problem, but if there were some problem with the cross-compiler it might make the _Bool missing.
The instructions for CLFS 3.0 use gcc 4.8.3 (versions of all of the parts do matter). However, the error message cited here looks like a recent report due to gcc 5 — which is addressed in ncurses 6.0

static compile glfw

I'm trying to compile glfw as static link on Linux Mint (based on Ubuntu 10.04) using GCC 4.4.3.
Inside my project directory i got "external/glfw" which contains glfw 2.7.1 source. I've compiled it by running "make x11-install" which gives:
/usr/local/include/GL/glfw.h
/usr/local/lib/libglfw.a
/usr/local/lib/pkgconfig/libglfw.pc
i also got this simple code in test.c:
#include <stdio.h>
#include <stdlib.h>
#include "external/glfw/include/GL/glfw.h"
int main( int argc, char const* argv[] )
{
if( !glfwInit() ){
fprintf( stderr, "glfwInit Failed\n" );
}
glfwOpenWindowHint( GLFW_FSAA_SAMPLES, 4 );
glfwOpenWindowHint( GLFW_OPENGL_VERSION_MAJOR, 3 );
glfwOpenWindowHint( GLFW_OPENGL_VERSION_MINOR, 1 );
glfwOpenWindowHint( GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE );
// Open a window and create its OpenGL context
if( !glfwOpenWindow( 1024, 768, 0,0,0,0, 32,0, GLFW_WINDOW )){
fprintf( stderr, "glfwOpenWindow failed\n" );
glfwTerminate();
return -1;
}
return 0;
}
i'm trying to compile glfw as static link and compiled the code using gcc with flags:
/usr/bin/gcc `pkg-config --cflags libglfw` -o test test.c \
`pkg-config --libs libglfw` -lXrandr -lX11 -lGLU -lGL -pthread -lm
and it doesn't give me any error. but when i try to execute the binary it shows that i've failed to call glfwOpenWindow.
could any one help me please? thank you for your time guys!
cheers!
P
EDIT 1: I think the problem lies with the linking process and not the code. Because if i have libglfw2 and libglfw-dev installed (ubuntu packages), then the executable runs just fine. What i want here is to have glfw statically linked and not to rely on distro package share libs for the binary to run.
EDIT 2 as per datenwolf suggestion i tried to debug with gdb. i never use gdb before but i use perl debugger a lot. somehow they share a lot of similarities. i recompile glfw and my test.c with -ggdb.
flowing with gdb it shows that my code goes into glfwOpenWindow() which is in "window.c" in glfw source code. since i'm new to gdb i don't know how to evaluate expression or get the value of variables. based on quick search on google all i know is "whatis" to see the date type. but i think my code stops when it reached line 484 in "window.c"
if( wndconfig.glProfile &&
( wndconfig.glMajor < 3 || ( wndconfig.glMajor == 3 && wndconfig.glMinor < 2 ) ) )
{
// Context profiles are only defined for OpenGL version 3.2 and above
return GL_FALSE;
}
now i'm not sure how come using static link glfw thinks i'm not on OpenGL 3.2 and above, while having libglfw2 installed it works just fine?
thanks for your help guys! especially datenwolf!
EDIT 3 Thanks for the help guys. After some help from people in stackoverflow and old nabble I manage to write it down what needs to be done to statically linked GLFW and GLEW and put it on http://www.phacks.net/static-compile-glfw-and-glew/
So your error is that the call to glfwOpenWindow failed? No unresolved symbol or shared object not found messages before even main() gets called? Then you successfully linked against GLFW statically.
I think your problem lies in the parameters you pass to glfwOpenWindow:
glfwOpenWindow( 1024, 768, 0,0,0,0, 32,0, GLFW_WINDOW )
So you're requesting zero red, green or blue bits per channel, but 32 depth bits. I doubt your system supports that. I'd try
glfwOpenWindow( 1024, 768, 8,8,8,0, 24, 8, GLFW_WINDOW )
that's what most systems support well.
Your example program requests OpenGL 3.1 and a context profile. Profiles are only defined for OpenGL 3.2 and above, which is most likely why glfwOpenWindow fails in this case. To fix this, either request a version above or equal to 3.2, or remove the request for a context profile.
For more information about modern OpenGL context creation with GLX, upon which this part of GLFW is a thin layer, see
http://www.opengl.org/registry/specs/ARB/glx_create_context.txt .

Using GSL with cygwin g++

trying to get the Gnu Scientific Library (gsl) to work in cygwin g++.
Cygwin is installed and updated with all default parameters and includes gsl:runtime, gsl-apps and gsl-doc. I am trying the example program given in the gsl website:
http://www.gnu.org/software/gsl/manual/html_node/An-Example-Program.html
include
#include <gsl/gsl_sf_bessel.h>
int
main (void)
{
double x = 5.0;
double y = gsl_sf_bessel_J0 (x);
printf ("J0(%g) = %.18e\n", x, y);
return 0;
}
Would anyone be so kind as to give me a version of the above program that actually works with g++? The header file is nowhere to be found with this default installation. How do I access the dll?
I also tried to install the non-default 'gsd-devel' (the developper tools), which gives me access to the header file but when I compile I am getting "Undefined reference to 'gsl__sf_bessel_J0'", even though the header file is found.
Any help greatly appreciated!
I am new to CygWin & GSL as well, and I after some research, I think the answer lies in the fact that the required libraries are not being linked. There is a clever little tool which comes with GSL called gsl-config. You can use this to get the linking information to the libraries. So in your case, the code:
#include <gsl/gsl_sf_bessel.h>
#include <stdio.h>
int
main (void)
{
double x = 5.0;
double y = gsl_sf_bessel_J0 (x);
printf ("J0(%g) = %.18e\n", x, y);
return 0;
}
can be compiled using g++ bessel.cpp -lm -lgsl -o bessel.out -L/usr/bin where the -lm -lgsl -L/usr/bin bit is the output of typing gsl-config --lib-without-cblas. Test using ./bessel.out.
Hope this helps, T

Resources