0

I downloaded the 64-bit Dlang DMD Fedora/CentOS package and installed inside a virtual 64-bit Scientific Linux machine using rpm -i. Works just fine.

Moving to a 64-bit SL physical machine, I installed the same package but running dmd or rdmd even without any arguments gives an error Floating-Point Exception. The bad thing, the OS won't boot! It just freezes on a black screen with blinking cursor.

Note: I'm not sure if it is related, but the PC with the virtual machine has i5-2400 and the other crashing PC has an i7-4790.

Update: Now after nothing done except a fresh OS install, the OS boots fine after the package installed.

Update 2: I downloaded this package that contains pre-built binaries and some source (I don't know for what!) and I downloaded the source from GitHub, even the pre-built binaries give the same error Floating-point exception.

Thanks for any assist!

3bdalla
  • 407
  • 1
  • 10
  • 28
  • 5
    A dmd package shouldn't affect the OS booting at all... I can't imagine how it would, you probably have some other problem. – Adam D. Ruppe Mar 28 '16 at 13:11
  • The same steps were done in both the virtual machine and that physical machine except that the VM asked for dependencies (glibc-devel, libcurl) and the physical asked for (glibc-devel, libcurl and libgcc), in both cases all of the requested were 32-bit bit libs despite the system being 64-bit :\. The weird thing even running the command with no arguments it gives an exception, and the immediate reboot after that, bye bye OS :\ – 3bdalla Mar 29 '16 at 06:35
  • It makes no sense why it would affect your OS again. Are you sure you don't have some corrupt drivers or something that screws you up when your OS attempts to do something? Or at any case some defect hardware? – Bauss Mar 29 '16 at 07:22
  • The effects I'm getting recently have no clue of what might be the problem. First it was not booting now it does. Built on 64-bit VM and not running on a physical one. I started to surrender actually :D – 3bdalla Mar 29 '16 at 08:09
  • The .xz package source is the source for the binaries it has. You should try building from the source in there: `cd dmd2/src/dmd; make -f posix.mak ;` then run the `./dmd` from there and see what happens. – Adam D. Ruppe Mar 29 '16 at 13:16
  • do you have actual version of microcode for your cpu? In your distribution package would be called microcode_ctl – Kozzi11 Mar 30 '16 at 08:38
  • @AdamD.Ruppe, Ironically that makefile requires dmd :\ – 3bdalla Mar 30 '16 at 19:15
  • @Kozzi11 I didn't understand your point. – 3bdalla Mar 30 '16 at 19:16
  • Ah, geeze, I forgot dmd has been ported to D now. You should be able to grab one of the older C++ versions like this: http://dlang.org/changelog/2.068.2.html and compile it, then if you want to update, use the old version to compile the new version. – Adam D. Ruppe Mar 30 '16 at 23:50
  • Sometimes there can be some errors in CPU itself, I have already seen lots of wierd errors cause by this. And after installing ucode it has been fixed – Kozzi11 Mar 31 '16 at 12:19
  • http://stackoverflow.com/questions/4366837/what-is-intel-microcode – Kozzi11 Mar 31 '16 at 12:22

0 Answers0