Building rocksdb on my Ubuntu 20.04 box. I get the following error:
In file included from db/malloc_stats.cc:16:
./port/jemalloc_helper.h:63:29: error: 'je_malloc' attribute directive ignored [-Werror=attributes]
63 | __attribute__((__weak__));
| ^
I'm compiling using a simple make -j and I have all the listed dependencies installed, including libjemalloc-dev, but I've tried uninstalling it to no avail. gcc version is 9.3.0. Reinstalling it as well. These attribute directives are an area of C++ I'm not at all familiar with and I have no idea how to diagnose this problem. If I pass DISABLE_WARNING_AS_ERROR, I end up with linker errors, so clearly this error is meaningful. Notably, I was able to build this quite recently on this machine, and I don't recall changing anything that would have affected this. I did system updates, but nothing else that would possibly cause this that I know of. I've checked previous commits of rocksdb and I get the same error so the problem is definitely on my end somehow, but I've checked with coworkers and none of them have this problem. Any ideas or advice on how to diagnose this issue would be appreciated.
EDIT: I've just tried running make alone, and while it took forever, the build succeeded. This is not practical and I'm still at a complete loss as to how to diagnose this issue.
EDIT 2: The successful build with make is not consistent, though I am confident that it succeeded at least once. When it doesn't succeed I get the same error as above.
Related
I compile Apache Arrow (https://arrow.apache.org/) with CMake 3.15 and gcc/g++-7 (7.5.0) and it goes well. However, when I upgrade gcc/g++ to 8(8.4.0) and 9(9.3.0) with the same CMake version, I got the following errors:
/tmp/ccrlCxYO.s: Assembler messages:
/tmp/ccrlCxYO.s:5651: Error: unsupported instruction `vmovdqu'
make[2]: *** [src/parquet/CMakeFiles/parquet_objlib.dir/build.make:194: src/parquet/CMakeFiles/parquet_objlib.dir/encoding.cc.o] Error 1
The target file (encoding.cc) is a pure C++ file. It uses Intel Intrinsics, but does not contain any assembly code.
This is the first time I see an "Assembler message" error. So I request some help understanding what it means. My question:
When would the assembler complain about unsupported instruction? I have seen unsupported instruction at runtime before, but not this "Assembler message". As this happens after upgrading GCC, I guess this is a new feature of the new compiler/assembler? I cannot find any document, so if anyone can point to me any doc explaining this it would be very appreciated.
Adding "-mavx" to target_compile_options does not solve the problem. Anyone has a suggestion of solution to the problem?
Thank you!
TLDR: I found the solution is to add "-mavx512bw" to target_compile_options
Please continue reading if you want to hear more detail about the root cause, and how I found it.
After googling a bit I found this webpage talking about a bug of GNU AS. https://www.mail-archive.com/bug-binutils#gnu.org/msg30524.html
That webpage reports that AS does not recognize "vmovdqu16", which needs the support of AVX512VL+AVX512BW. However, the assembler reports an error message saying "vmovdqu" is not supported.
This reminds me that I may encounter the same issue. The AS actually receives "vmovdqu8/16/32" but it reports "vmovdqu". This error message is very misleading because "vmovdqu" and "vmovdqu16" need different instruction set supports. The former only need AVX, but the latter need AVX512BW+AVX512VL.
I decided to give it a try and add -mavx512bw to the compile option ( I already have avx512vl before). It actually fixes the problem.
So I think the whole story is: the newer version of GCC uses some new SIMD instruction, which the old GCC did not use.
Hope this helps someone who also run into similar problems.
I have an OCaml program that worked fine on Ubuntu 16 but when recompiled and run on Ubuntu 20 I get the following error:-
$ ocamldebug ./linearizer
OCaml Debugger version 4.08.1
(ocd) r
Loading program... done.
Time: 89534
Program end.
Uncaught exception: Sys_error "Illegal seek"
(ocd) b
Time: 89533 - pc: 624888 - module Netaccel_link
No source file for Netaccel_link.
I thought this was due to missing dev libraries but:-
$ sudo apt install libocamlnet-ocaml-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libocamlnet-ocaml-dev is already the newest version (4.1.6-1build6).
0 upgraded, 0 newly installed, 0 to remove and 20 not upgraded.
What setup step am I missing on Ubuntu 20?
This looks like a regression bug in libocamlnet and you should report an issue there or, I am a bit pessimistic that you will get any response, you can try to debug the issue yourself.
The problem that you are facing has nothing to do with missing libraries (they will be reported during installation or, if the package is broken, end up in linker errors). It may result, however, from some misconfiguration of the system. If that is true, then you're lucky as you can fix it yourself.
I will give you some advice that might help you in debugging this issue. For more, please try using discuss.ocaml.org as a more suitable media (SO doesn't favor this kind of a discussion and we might get deleted by admins).
The illegal seek exception is thrown when the seek operation is applied on a non-regular file, aka ESPIPE Unix error. So check your inputs. It could be that what was previously regarded as a file in Ubuntu is now a pipe or a socket.
Try to use ltrace or strace to pinpoint the culprit e.g.,
ltrace ./linearizer
or, if it overwhelms you, try strace
strace ./linearizer
Instead of using ocamldebug you can use plain gdb. You can use gdb's interfaces to provide the path to the source code (though most likely it won't work since ocamlnet is not compiled with debug information). I believe that it will give you a more meaningful backtrace.
Instead of using the system installation try using opam. Install your dependencies with opam and try older versions as well as newer versions of the OCaml compiler. Also, try different versions of ocamlnet. Ideally, try to reproduce the environment that used to work for you.
When nothing else works, you can use objdump -d and look at the disassembly of your binary. OCaml is using a pretty readable and intuitive name mangling scheme (<module_name>__<function_name>_<uid>), so you can easily find the source code (search for <module_name>.ml file and look for the <function_name> there)
Finally, just use docker or any other container to run your application. Consider switching from ocamlnet to something more modern and supported.
I am trying to compile OpenCL kernels on OS X. Everything is ok when there are just a few lines. However, after the code grows over 1.5k lines, clGetProgramBuildInfo with CL_PROGRAM_BUILD_LOG flag returned "Compile Server Error." every time. I googled but found nothing about it. Could anyone help me?
You can learn the meaning of OpenCL error codes by searching in cl.h. In this case, -11 is just what you'd expect, CL_BUILD_PROGRAM_FAILURE. It's certainly curious that the build log is empty. Two questions:
1.) What is the return value from clGetProgramBuildInfo?
2.) What platform are you on? If you are using Apple's OpenCL implementation, you could try setting CL_LOG_ERRORS=stdout in your environment. For example, from Terminal:
$ CL_LOG_ERRORS=stdout ./myprog
It's also pretty easy to set this in Xcode (Edit Scheme -> Arguments -> Environment Variables).
Please find the original answer by #James
This unhelpful error message indicates that there is bug in Apple's compiler. You can inform them of such bugs by using the Apple Bug Reporting System.
I do think that some of my problems concerning adding new functionality to old C++ code can be solved elegantly using AOP. Now, my first idea was to download AspectC++ and just start working. However, it doesn't seem to be that simple:
The Visual Studio integration thingy by pure systems has been updated for the last time about 5 years ago, adding support for VS '05. '10 (which I'm using) isn't detected during installation which in turn results in the installation being canceled.
ACDT was updated the last time Feb '07, Eclipse 3.2 being the last one supported, installation on current Eclipse fails.
Simply trying to compile the examples that come with AspectC++ doesn't work either:
username#username-VirtualBox:/media/sf_Temp/aspectc++$ make
make -C examples/coverage
make[1]: Entering directory `/media/sf_Temp/aspectc++/examples/coverage'
Compiling main.cc
make[1]: /media/sf_Temp/aspectc++/ag++: Command not found
make[1]: *** [Junk/main.o] Error 127
make[1]: Leaving directory `/media/sf_Temp/aspectc++/examples/coverage'
make: *** [coverage.make] Error 2
username#username-VirtualBox:/media/sf_Temp/aspectc++$
This "command not found" is weird, as simply running ag++ works (albeit it then of course complains about having no input files).
Soooo ... I'm kind of lost now. Any help on where to find a working manual for performing the first steps or some hint concerning what I'm doing wrong would be appreciated. Or is AspectC++ just too outdated/unusable/whatever for people to use it (which would explain the lack of some simple first-steps-manual which usually can be found by the hundreds)?
Thanks in advance.
I'm the AspectC++ project leader. If you need help, the best way is to subscribe to the AspectC++ user mailing list (visit www.aspectc.org and click on "support") and post a question there. It is not possible to be aware of all questions being posted anywhere on the web. Sorry. Yet, you are really welcome on our mailing list! :-)
In your special case, the error message sounds as if ag++ hadn't found ac++. These two binaries have to reside in the same directory. ag++ is just a wrapper that calls ac++, which performs the actual code transformation, and g++ for the compilation into an object file.
I already asked this question in the nvidia forum but never got an answer link.
Every time I try to step into a kernel I get a similar error message to this:
__device_stub__Z10bitreversePj (__par0=0x110000) at
/tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c:10
10 /tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c: No such file or directory.
in /tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c
I tried to follow the instructions of the cuda-gdb walkthrough by the error stays.
Has somebody a tip what could cause this behaviour?
The "device stub" for bitreverse(unsigned int*) (whatever that is) was compiled with debug info, and it was located in /tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c (which was likely machine-generated).
The "No such file" error is telling you that that file is not (or no longer) present on your system, but this is not an error; GDB just can't show you the source.
This should not prevent you from stepping further, or from setting breakpoints in other functions and continuing.
I was able to solve this problem by using -keep flag on the nvcc compiler. This specifies that the compiler should keep all intermediate files created during the compilation, including the stub.c files created by cudafe that are needed for the debugger to step through kernel functions. Otherwise the intermediate files seem to get deleted by default at the end of the compilation and the debugger will not be able to find them. You can specify a directory for the intermediate files as well, and will need to point your debugger (cuda-gdb, nsight, etc) to this location.
I think I had such problem once, but can't really remember what was it caused with. Do you use textures in your kernel? In that case you couldn't debug it.