I have updated macos to Mojave and after updating the command tools and when I run my c++ program I am getting the following error
dyld: __dyld section not supported in /Users/rameshkolluru/Dropbox/1D_Multiphase_Euler_Equations_FVM/./1D_Multiphase_Euler_solver
Abort trap: 6
Any help is appreciated
Are you compiling with the -pg option to enable profiling? If yes, try to remove that flag.
Using -pg Apple LLVM version 10.0.0 (clang-1000.11.45.2) still seems to add a __DATA,__dyld section to your executable, which dyld in Mojave does not seem to support/accept any more.
Related
I am currently having an issue with Octave install in Archlinux. I am not able to load the current version of Octave 4.2.1 in Arch. It shows the following message -
/usr/lib/octave/4.2.1/exec/x86_64-pc-linux-gnu/octave-gui: error while loading shared libraries: libgfortran.so.3: cannot open shared object file: No such file or directory
This problem with libgfortran.so.3 is not rare. Here are two similar problems happening in R 1 and 2. If somebody using Octave on Archlinux came across this issue, can you share how to resolve it. Thanks.
From the comments it became apparent that the solution from the referenced question R v3.4.0-2 unable to find libgfortran.so.3 on Arch needs to be appended, because the way the older GCC versions will be typically installed in Arch Linux is in a different path.
So, one must find, where the older version is installed, like
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libgfortran.so.3
(depending on the exact GCC version)
and then add the version to LD_LIBRARY_PATH or make a symlik of the library from the above path to /usr/lib64/.
I got this issue because I installed earlier additionally openblas-lapack from AUR for better octave matrix multiplication performance. Updating openblas-lapack to newest version in AUR did the trick for me.
When trying to use ChromeDriver 2.31 in CentOS 7 I get the following error:
version 'GLIBC_2.18' not found
ChromeDriver developers confirm that glibc library dependency has been promoted to 2.18, while CentOS 7 has version 2.17.
Related links:
Announcing ChromeDriver 2.31
ChromeDriver Issue #1894
ChromeDriver Issue #1772
Is there a way to make it work without switching to another OS?
The Chromium developers are aware of the issue and working on a fix:
glibc dependency creeped up to 2.18 in M61, breaking EL7 support
During the switch to libc++, they accidentally referenced a new symbol from the glibc version in their sysroot, __cxa_thread_atexit_impl. But this was only introduce in glibc 2.18, and Red Hat Enterprise Linux 7 only has version 2.17. Apparently, for their use cases, libc++ works well enough without this symbol (similar to libstdc++ from GCC), so they just need to tweak their build not to use it, and Chromium (and thus Chrome Driver and Chrome unstable) should work again soon.
As an end user or even software developer who cannot rebuild the software in question (or maybe just does not want to invest such a non-trivial effort), there is little one can do about such glibc version dependencies. Therefore, it is pretty much a requirement that all builds happen against a build environment which matches the oldest operating system version one wants to support.
Dependency to GLIBC 2.18 have been removed in Chromedriver 2.32, so that version is safe to use on Centos 7.
Back to chromedriver 2.30 and it work with google-chrome-stable.x86_64 0:60.0.3112.113-1 on CentOS 7
I'm running Python27 x32 and getting this error:
Could not load "nvrtc64_75.dll": %1 is not a valid Win32 application.
I've also tried with cuda8.
As I realized, NVRTC docs list x64 as a requirement:
NVRTC requires the following system configuration:
Operating System: Linux x86_64, Linux ppc64le, Linux aarch64, Windows x86_64, or Mac OS X.
(nvrtc64_75.dll really does have 0x8664 in IMAGE_FILE_HEADER and 0x20b (pe32+) magic.)
I'm trying to use libgpuarray's pygpu with theano and I've previously built it with Win32 mingw.
My understanding now is that I'll need to install an x64 version of python and start from there. I know I could use conda instead and the docs in libgpuarray talk about msvc, btw. it worked with mingw so far.
Am I interpreting this right? Is NVRTC really have no working Win32 edition?
edit: got the same %1 is not a valid Win32 error with conda x32 and msvc (no real surprise here).
Just as the documentation you linked indicates, NVRTC requires a 64-bit environment.
So I downloaded the latest Cuda (5.0.35) script to install Cuda on my desktop on which I have Debian (kernel 2.6.32).
When I ran the script though I get an error on the log which says:
The compiler used to compile the kernel (gcc-4.3) does not exactly match the current compiler (gcc-4.7)
So I looked to install gcc-4.3 from the repositories but it isn't there. Then I downloaded the gcc-4.3 package separately but when I try to install it I get many conflicting dependencies so installing it is really not an option. I installed gcc-4.4 which is in the repositories and changed the soft link for gcc to link to the gcc-4.4 version but I get the same message above
The compiler used to compile the kernel (gcc-4.3) does not exactly match the current compiler (gcc-4.4)
So the question is, is there a way that I can install the driver successfully without relying on the gcc-4.3?
I installed a 3.2 kernel which was compiled with gcc-4.6 and that worked for me. You could also compile the old kernel using gcc-4.7 although I tried it and had some errors. The problem is that Debian uses a very old kernel so it was compiled with gcc-4.3.
I had trouble with the gem at first but got it to work when I installed the 64-bit MySQL and reinsatlled the gem with arch flags.
So it work in rails. The error I used to get was
uninitialized constant MysqlCompat::MysqlRes
but that is now gone :)
However in Xcode when I run a RubyCocoa project I still get the old error of
uninitialized constant MysqlCompat::MysqlRes
Does anyone know why this may be?
Is it because the gdb is 64-bit?
How can it work in Rails but not in RubyCocoa?
A little debugging shows that it fails to load mysql_api.bundle
/Library/Ruby/Gems/1.8/gems/mysql-2.8.1/lib/mysql_api.bundle:
dlopen(/Library/Ruby/Gems/1.8/gems/mysql-2.8.1/lib/mysql_api.bundle, 9): no suitable image found.
Did find: (LoadError) /Library/Ruby/Gems/1.8/gems/mysql-2.8.1/lib/mysql_api.bundle: mach-o, but wrong architecture -
/Library/Ruby/Gems/1.8/gems/mysql-2.8.1/lib/mysql_api.bundle from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require'
The problem might be that xcode uses another version of the ruby framework than you are using normally, I had that trouble and solved it somehow.
The architecture mismatch might be some other thing though:
/System/Library/Frameworks/Ruby.framework
I had the same problem and it had something to do with an older MySQL installation if I remember correctly. I installed the 32-bit version by accident, noticed the mistake and installed the 64-bit one.
I got rid of the error by removing MySQL as described here: How do you uninstall MySQL from Mac OS X and reinstalling the latest version with arch flags.
Did you try this?