I have some (larger) code developped under linux. Once I realized I would need it under windows I installed a cross compiler under linux and all went well.
Now the code should be managed futher without the need of the virtual machine. Therefore I installed mingw and tried to compile the code under windows.
I get a DLL without any warnings or similar.
But:
As soon as I tried to use the DLL (bind it in Matlab) I get an error about a module that could not be found. Using Dependency walker I get an error about
At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
I saw, that e.g. the function InterlockedDecrement from the kernel32.dll is red (missing). In the mingw installation I find a libkernel32.a that has two functions according to this function (output from nm):
00000000 T _InterlockedDecrement#4
00000000 I __imp__InterlockedDecrement#4
That looks quite good so far. In c:\Windows\System32\kernel32.dll there is a function InterlockedDecrement according to pexport.
So my question is: Where is this error coming from? What do I do wrong?
Related
I like windows gcc equation.com because it like ran natively just like windows compiler. However :
I will need some dll's that not included on distributed package. if i compiled a windows equation.com gfortran program like using Openblas, it will need libgcc_s_seh-1.dll libgfortran-5.dll libquadmath-0.dll libwinpthread-1.dll.
I could find it on web. But how to make it statically linked, i saw libgcc.a libgfortran.a libquadmath.a libpthread.a so i dont have to copy the dll from other. It is possible ?
For several c source code it need include <sys/resource.h> that not included. It's compatible with resource.h from where. After just copied from others, and recompile.
I got error :
c:\gcc\x86_64-w64-mingw32\include\sys\resource.h:74:29: error: unknown type name 'id_t'; did you mean 'pid_t'?
Is there any forum for this type gcc? Is there any debugger for windows gcc that friendly like VisualStudio Community for Intel Fortran.
Regards.
I am patching code into my car's ECU. This has a Motorola MC68376 processor, so I'm using the appropriate CPU32 instruction set.
I want to continue to write in assembly code so that I can explicitly manage control registers, RAM access and allocation, as well as copying code structures which are already in use.
My first patch was successfully compiled in EASy68k, but that program does not support the full instruction set for the CPU32. For example, the DIVS.L command is not supported, so I cannot take a quotient of a 32-bit value.
Thus, before writing my own compiler out of sheer incompetence with available tools, I'm looking for an easier path. I read that gcc has the capability to compile code for the CPU32, but I have failed to get it to work.
I'm using MinGW's gcc (6.3.0) and Eclipse (2020-03). I added the '-mcpu32' or '-march=cpu32' flags to the compiler call, according to:
https://gcc.gnu.org/onlinedocs/gcc/M680x0-Options.html
Unfortunately this returns an error:
gcc: error: unrecognized command line option '-mcpu32'; did you mean '-mcpu='?
or
error: bad value (cpu32) for -march= switch
May I please have some advice for making this work? Does anyone know of a better CPU32 compiler that works with Eclipse?
I did not understand that gcc is conventionally distributed as binary files that are compiled with different functionality to suit the needs of a given user.
There seem to be two paths forward:
1) compile my own cross-compiler version of GCC
2) download a pre-compiled cross-compiler version of GCC
I chose to follow route 2).
I began the process of installing the 'Windows Subsystem for Linux' and Ubuntu 20.04 Focal Fossa, because I found a pre-made compiler that should be capable of performing cross compilation for the m68k processor: "gobjc-10-m68k-linux-gnu"
https://ubuntu.pkgs.org/20.04/ubuntu-universe-i386/gobjc-10-m68k-linux-gnu_10-20200411-0ubuntu1cross1_i386.deb.html
While I was installing that, I also found an m68k-elf gcc toolchain that is pre-compiled for windows 10:
https://gnutoolchains.com/m68k-elf/
I played with the latter for much of today. Although I was unable to get the toolchain integrated well with Eclipse, it works from the command line to compile a *.s assembly code file. This includes compatibility with the '-mcpu32' flag that I wanted at the outset.
There is still a lot for me to figure out, even after floundering through learning gcc's assembler directives (https://www.eecs.umich.edu/courses/eecs373/readings/Assembler.pdf) and the differences in gcc's assembly syntax compared to the MC68k reference manual (https://www.nxp.com/files-static/archives/doc/ref_manual/M68000PRM.pdf).
I can even convert the code section of the output file to be a proper s-record by using objcopy with the '-O srec' and '--only-section=.text' flags. This helps me patch the code into my ECU.
Thus I've answered my original question.
This question follows How to install RRDTool::OO on Strawberry perl
I thought it would be better to create a new question, for the sake of clarity.
Resume:
One wants to install the RRDTool::OO perl library on Windows. To do that, the library RRDTool is required. It is a C lib and must be compiled manually.
First thing to be compiled is the rrd.sln project. This runs smoothly with visual C++
Second thing to do is to compile RRDs.XS. This doesn't work at all with Strawberry perl.
1) I launched perl ntmake-build to generate a makefile for windows.
2) Then launched dmake to compile the module. A bunch of compilation error is displayed.
Issues come from the fact that the ntmake-build file use statics path that are not right for Strawberry perl. But even after having correcting them, errors are still thrown:
RRDs.o:RRDs.c:(.text+0x971): undefined reference to `rrd_clear_error'
RRDs.o:RRDs.c:(.text+0x985): undefined reference to `rrd_restore'
RRDs.o:RRDs.c:(.text+0x9f7): undefined reference to `rrd_test_error'
RRDs.o:RRDs.c:(.text+0xafd): undefined reference to `rrd_clear_error'
......................
collect2: ld returned 1 exit status
dmake.exe: Error code 129, while making 'blib\arch\auto\RRDs\RRDs.dll'
Does someone has ever compiled this module on windows/Strawberry?
It seems that it is not possible - or complicated due to several hacks to create and apply to the library - to compile RRDs.XS on windows server 2008 64 bits edition. Here are several points:
There is no PPM package for RRDTool (at least on the ActiveState repositories).
Anyway, Strawberry perl x64 does not embed a PPM tool.
The RRDTools makefiles are written for an AS 32 bits installation (mainly due to the static path for perl libraries, maybe I missed other static path - for C libraries for example).
Those are the main points I can list, that avoid a clean installation of RRDTool on Strawberry Perl.
This means that the frontend module RRDTool::OO can also not be used.
I'm trying to build the double-conversion package from Hackage. It builds OK but ghci can't load it. The complaint is:
Loading package double-conversion-0.2.0.0 ... linking ... <interactive>:
/home/me/.cabal/lib/double-conversion-0.2.0.0/ghc-7.0.4/HSdouble-conversion-0.2.0.0.o:
unknown symbol `_ZNK17double_conversion6Double5valueEv'
The nm output shows that the symbol is weak:
nm /home/me/.cabal/lib/double-conversion-0.2.0.0/ghc-7.0.4/HSdouble-conversion-0.2.0.0.o \
| grep _ZNK17double_conversion6Double5valueEv
00000000 W _ZNK17double_conversion6Double5valueEv
This is the only weak symbol in the file, and indeed, as far as I can tell, in the entire world of GHC-compiled packages.
The problematic function is apparently a FFI one, written in C++ and defined inline in double-conversion/src/double.h. It's not the only inline function there, but only this one gets labelled weak.
As a stopgap measure I have moved the function out-of-line, and the package now loads. But there's obviously some problem somewhere in there. Why this function is weak? Why other functions are not? Should ghc complain at weak symbols? Should I file a bug, and if so, who should get it (double-conversion, gcc, ghc, someone else?)
System data: Gentoo Linux, gcc-4.4.5, ghc-7.0.4, cabal-1.10.2.0.
This ticket on GHC Trac looks relevant: Can't use ghci with a library linked against libstdc++. This looks like a Gentoo (or possibly GCC 4.4)-specific problem - the .o file in question doesn't contain any weak symbols on my system (I tested on Ubuntu Natty with GCC 4.5.2 & GHC 7.0.3/7.0.4). I suggest you file a ticket on GHC Trac. Incidentally, I can reproduce #5289.
My setup is as follows:
OS: Windows 7 Home Premium 64-bit
Eclipse: Helios 3.6.1 64-bit with CDT
and Photran
Java SE Runtime
Environment: 1.6.0_21
Java Hotspot: 64-bit Server VM
(build 17.0-b17, mixed mode)
Cygwin 1.7.2 (32-bit)
My initial test Fortran application simply prints 'Hello World!' and exits.
The code builds and runs fine, albeit with the following 2 Warnings in the Problems tab in Eclipse
Description Resource Path Location Type
Error launching external scanner info generator (gcc -E -P -v -dD C:/Users/Joe/workspace/.metadata/.plugins/org.eclipse.cdt.make.core/specs.c) HelloFortran Unknown C/C++ Problem
Error launching external scanner info generator (gcc -E -P -v -dD C:/Users/Joe/workspace/.metadata/.plugins/org.eclipse.cdt.make.core/specs.c) HelloFortran Unknown C/C++ Problem
The problem comes when trying to debug the app as a Local Fortran Application which results in this error:
cygwin warning:
MS-DOS style path detected: C:\Users\Joe\workspace\HelloFortran
Preferred POSIX equivalent is: /cygdrive/c/Users/Joe/workspace/HelloFortran
.gdbinit: No such file or directory.
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
auto-solib-add on
Undefined command: "auto-solib-add". Try "help".
Error: dll starting at 0x76ba0000 not found.
Error: dll starting at 0x75230000 not found.
Error: dll starting at 0x76ba0000 not found.
Error: dll starting at 0x76aa0000 not found.
[New thread 7060.0x10dc]
[New thread 7060.0x16c0]
I'm guessing the entry points aren't found because it's expecting 32-/64-bit DLL and getting the other type (correct me if I'm wrong). The GDB version is as follows:
GNU gdb 6.8.20080328 (cygwin-special)
GDB configured as "i686-pc-cygwin"
Running GDB from the command-line gives:
[New thread 5768.0x15a0]
Error: dll starting at 0x76ba0000 not found.
Error: dll starting at 0x75230000 not found.
Error: dll starting at 0x76ba0000 not found.
Error: dll starting at 0x76aa0000 not found.
[New thread 5768.0x46c]
hellofortran () at ../HelloFortran.f90:1
1 program HelloFortran
Current language: auto; currently fortran
If I'm reading that correctly the application does run in GDB and I am able to step through it, but what are the missing DLL errors about?
Dependency Walker gives the following errors for my HelloFortran.exe
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
The missing DLLs seem to be IESHIMS.DLL (2) which from my quick research doesn't seem to be a big issue but I don't see any reason my application would need to reference this DLL so I don't think this is leading to the errors in GDB.
All of the modules have a CPU type of x64 except for:
CYGGCC_S-1.DLL
CYGGFORTRAN-3.DLL
CYGWIN1.DLL
HELLOFORTRAN.EXE
which have a CPU type of x86
I'm concerned the missing DLL errors could harm my ability to debug my program properly (although the program will eventually run on a Unix-based HPC so I shouldn't run into these issues there since all those DLLs seem to be to do with Cygwin).
My questions:
Why do I get missing DLL errors? (Would switching to 32-bit versions of Eclipse/JVM etc fix this?)
Am I
okay to continue, or should I solve
the missing DLL errors (and if so,
how)?
Edit: My test program is as follows:
program HelloFortran
! Force variable declaration
implicit none
! Print 'Hello World!' to the main output
write (*,*) 'Hello World!'
! End program
end program HelloFortran
Why do I get missing DLL errors?
When Win/x64 sends a DebugEvent to 32-bit process about a 64-bit DLL that is part of that process, it necessarily truncates the load address (64-bit load address doesn't fit into 32-bit LPVOID). The end result is that the debugger sees a DLL load event, but can't find any DLL at that address; so warns you.
(Would switching to 32-bit versions of Eclipse/JVM etc fix this?)
No: this is fundamental to debugging any 32-bit process on x64 (at least with 32-bit debugger). I think you would get rid of the warning if you use x64 version of GDB, but I am not sure if GDB/x64 can debug 32-bit processes on Windows (x86_64 GDB has no trouble with i386 processes on Linux due to "multi-arch" support; I don't know if "multi-arch" is present in Windows version).
I'm concerned the missing DLL errors could harm my ability to debug my program properly
You shouldn't be.
I don't see any reason my application would need to reference IESHIMS.DLL
What made you think it's IESHIMS.DLL?
More likely what you see is WoW64.dll and friends.
Every 32-bit application running on Win/x64 references WoW64.