Mirror of forum.nim-lang.org

5228 :: Cross compilation linux -> win + wine issue with file reading

• Arrrrrrrrr (orginal) [2019-09-26T12:48:49+02:00] view original

  I have an issue, and I'd like some guidance on how to solve this. I have this single line of code:

  writeFile("copy.jpg", readFile("nim_in_action_cover.jpg"))
  Run

  This is the image

  Under linux, a simple nim c -r Main.nim makes a copy as expected, now if a cross-compile it to windows and run it with wine: nim c -d:mingw --cpu:i386 Main && wine Main Makes the picture lose 2KB in the process and now is broken:

  
  ExifTool Version Number         : 11.63
  ExifTool Version Number         : 11.63
  File Name                       : copy.jpg
  Directory                       : .
  File Size                       : 71 kB
  File Modification Date/Time     : 2019:09:26 12:43:38+02:00
  File Access Date/Time           : 2019:09:26 12:43:45+02:00
  File Inode Change Date/Time     : 2019:09:26 12:43:38+02:00
  File Permissions                : rw-r--r--
  File Type                       : JPEG
  File Type Extension             : jpg
  MIME Type                       : image/jpeg
  Warning                         : JPEG format error
  Run

  Is this an issue with wine or a bug related to how nim cross-compiles code (CR/LF)?

---

• Araq (orginal) [2019-09-26T14:54:21+02:00] view original

  Seems unlikely as Nim only knows about binary files anyway. But maybe something like that is going on. Tried a hex editor to see what's left out?

---

• Arrrrrrrrr (orginal) [2019-09-28T18:25:31+02:00] view original

  Yes, the NULL character (00) appears to be missing. Weird because I have used wine for other software that opens files too and had zero issues. I tried using fread and I get the same result. It reads exactly the same amount of bytes, but the 00s are removed.

  So it must be some bug in wine, who knows.

---

• Araq (orginal) [2019-09-28T20:28:02+02:00] view original

  Well echo does swallow the zeros, but that's not what you use. Strange.

---

• sschwarzer (orginal) [2019-09-30T10:25:44+02:00] view original

  Have you tried reading the file and printing the start of its contents - at least up to and a bit beyond the first null byte as known from the hex editor - as hex strings to stdout? That way you could at least check if the problem already occurs when reading.

---

• Arrrrrrrrr (orginal) [2020-01-22T14:16:58+01:00] view original

  Just wanted to say that, for whatever reason, it is now working as intended.

---

• Araq (orginal) [2020-01-22T15:56:55+01:00] view original

  The reason is simple: We fixed it and also put the fix into the 1.0.x line.

---