I'm using 64 bit Cygwin on Windows 8.1 for some basic operating system development. I'd like to use the utilities that come with GRUB 2.00 (such as mkrescue and mkimage) as my kernel is Multiboot 2 compatible and I'm booting from CD.
I have no problems compiling all of the tools I need in Cygwin except for GRUB, which spits out the following errors:
libgrubkern.a(libgrubkern_a-getroot.o):getroot.c:(.text+0x215): undefined reference to `cygwin_conv_to_full_posix_path'
libgrubkern.a(libgrubkern_a-getroot.o):getroot.c:(.text+0x215): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `cygwin_conv_to_full_posix_path'
libgrubkern.a(libgrubkern_a-getroot.o):getroot.c:(.text+0x228): undefined reference to `cygwin_conv_to_full_win32_path'
libgrubkern.a(libgrubkern_a-getroot.o):getroot.c:(.text+0x228): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `cygwin_conv_to_full_win32_path'
collect2: error: ld returned 1 exit status
Makefile:16816: recipe for target 'grub-mkrelpath.exe' failed
This is obviously something to do with the conversion in Cygwin between Windows and Posix-style paths. Slightly frustrating because even something as big as the GCC cross-compiler were compilable with no such issue.
I have Googled the exact error, but get no hits in relation to GRUB. Does anyone have a solution for this?
Adam
Looks like I'm on a similar road to the one you're on. From what I've seen, that line of path functions was deprecated and removed, being replaced by a newer approach. I was able to get it to continue compiling, but hit a different, but probably unrelated error.
In the file util/getroot.c in the function grub_find_device() I replaced:
cygwin_conv_to_full_posix_path (path, fullpath);
cygwin_conv_to_full_win32_path (fullpath, winpath);
With the following:
cygwin_conv_path(CCP_WIN_A_TO_POSIX, path, fullpath, PATH_MAX);
cygwin_conv_path(CCP_POSIX_TO_WIN_A, fullpath, winpath, PATH_MAX);
Unfortunately I ran into this next:
TARGET_OBJ2ELF=../grub-pe2elf sh genmod.sh moddep.lst regexp.module.exe regexp.mod
./../grub-pe2elf: error: invalid symbol.
Another (less desirable, but maybe less irritating) solution I've found mentioned to this issue is trying to find an older version of Cygwin, or a 32 bit version of Cygwin that works with the version of GRUB you want. Unfortunately, that'd probably mean rebuilding all your tools again.
Either way, I'm going to see if I can fix this new problem, and if I do I'll let you know.
It's a long time since I posted the original question but I've just found it again. Just to say that the long-term answer for me turned out to be switching away from Cygwin and I'm now using Bash on Ubuntu on Windows which has been much more successful for all the utilities I'm using.
Related
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.
I'm trying to get mpich 3.0.4 installed right on my system (Mac OS X 10.10.2) from the shell (which I use with tcsh). So I tar-ed it, then configured (./configure --prefix=$DIR/mpich) it, and then entered make.
All seemed to go well, but at the end, I've got those two warnings appearing :
ld: warning: directory not found for option '-L./src/mpl'
ld: warning: directory not found for option '-L./src/openpa/src'
and when I test it later (with a test from the tutorial, so the error does not come from here), it prints the following :
ld: targeted OS version does not support use of thread local variables in _MPIU_Thread_CS_enter_lockname_recursive_impl_ for architecture x86_64
I would be very grateful for any kind of advice (having in mind that I am rather a beginner).
Thank you !
edit : for information, I'm using this tutorial : http://www2.mmm.ucar.edu/wrf/OnLineTutorial/compilation_tutorial.php#STEP2
This immensely frustrating bug hit several platforms, including MVAPICH. Fortunately, it has been fixed -- though I can't tell you exactly how:
http://trac.mpich.org/projects/mpich/ticket/1840
http://mailman.cse.ohio-state.edu/pipermail/mvapich-discuss/2013-April/004359.html
If you try 3.1.4 this problem should go away.
I'm using InstallJammer to build cross-platform installers for my application (Windows, Linux & Mac). However, InstallJammer development has been discontinued and the official forum is now closed.
I need to build the installkit for Windows, because I'll have to make some changes to the Windows install manifest, in order to add Windows 7 support (otherwise the installer displays the message "This program might not have installed correctly").
I grabbed the latest installkit sources from here: http://sourceforge.net/projects/installjammer/files/installkit/1.2.15/installkit-1.2.15.tar.gz/download
I found this topic http://www.installjammer.com/forums/viewtopic.php?f=3&p=9258 which helped me get started.
I grabbed latest version of MinGW and typed ./configure && make. It started the build process, but there was this error while trying to compile TCL:
c:/installkit-1.2.15/src/tcl/win/tclWinReg.c:750:29: error: lvalue required as increment operand
Since these sources are kind of old, I figured I should try with an older GCC version (I was using 4.7.2). So I downgraded MinGW's GCC to version 3.4.5 and tried again.
This time, TCL built fine. Everything was going well, until it failed to build something called 'miniarc' (I don't know what it is), with the following error message:
miniarc.o:miniarc.c:(.text+0x370c): undefined reference to `_imp__strtoull'
miniarc.o:miniarc.c:(.text+0x37c9): undefined reference to `_imp__strtoull'
miniarc.o:miniarc.c:(.text+0x3cb6): undefined reference to `_imp__strtoull'
miniarc.o:miniarc.c:(.text+0x3e78): undefined reference to `_imp__strtoull'
miniarc.o:miniarc.c:(.text+0x3e9f): undefined reference to `_imp__strtoull'
miniarc.o:miniarc.c:(.text+0x3ff5): more undefined references to `_imp__strtoull' follow
collect2: ld returned 1 exit status
Strange thing is that there's no reference to imp_strtoull inside miniarc.c.
Moving on, I tried to build it in Ubuntu, since I didn't know what else to do, and it worked! GCC version was 4.4.3. So I went and searched for GCC 4.4.3 for MinGW, but the closest version was 4.4.0. I grabbed these and tried again. Same tcl build error (regarding tclWinReg.c).
Then I went back to GCC 4.7.2 and replaced TCL & TK sources (8.4) with the latest ones (8.5) and tried again.
TCL and TK both built fine, and so did some other libs, but when it came to 'miniarc', it failed again. This time with a different error:
undefined reference to `TclIncrVar2'
Apparently, this function no longer exists in TCL 8.5.
So, I'm out of ideas. I even tried emailing the original (and only) InstallJammer developer, but still got no answer (I don't even know if his email is the same).
Does anyone have any suggestions?
EDIT: I should add that I have very little experience with Makefiles and the last time I coded in C was 8 years ago in college. So, I apologize if there is something obvious about all this that I didn't notice.
I don't like the solution, but here's how I got it working:
Using GCC 3.4.5, I started the make process by typing ./configure && make;
The make process stops with an error (mentioned above) when it reaches 'miniarc';
Then, manually, I built a DLL (strtoull.dll) from file strtoull.o (below is the exact command-line I typed);
gcc -pipe -shared -o strtoull.dll strtoull.o -lz -L/c/installkit-1.2.15/Windows/lib /c/installkit-1.2.15/Windows/lib/libtclstub84s.a"
After that, I copied strtoull.dll to miniarc/build and to windows/system32;
Then I entered folder miniarc/build and typed:
gcc -pipe -shared -o miniarc01.dll miniarc.o sha1.o md5.o -lz -L/c/installkit-1.2.15/Windows/lib "/c/installkit-1.2.15/Windows/lib/libtclstub84s.a" strtoull.dll
Finally, I typed make again so it could continue building the rest of the stuff.
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?
I'm on freebsd and trying to run uhd from: http://www.ettus.com/download This should normally run under freebsd, but I encounter problems when I try to build it like specified here:
http://www.ettus.com/uhd_docs/manual/html/build.html#build-instructions-unix
I get:
[ 73%] Building CXX object examples/CMakeFiles/benchmark_rx_rate.dir/benchmark_rx_rate.cpp.o
Linking CXX executable benchmark_rx_rate
../lib/libuhd.so.003.000: undefined reference to `uhd::set_thread_priority(float, bool)'
collect2: ld returned 1 exit status
*** Error code 1
Now this seems to be a linker error, but how to get rid of it? I tried setting the path using ldconfig but this hasn't changed a thing. Maybe some of you have an idea where I could continue searching.
If i get it right, libuhd get's built earlier by this CMake script. If it's true, this error indicates bug in their CMakeLists.txt files.
It looks like you are building examples of using libuhd. I doubt you are need them. So, either look for switches in your CMakeCache.txt and regenerate Makefiles or hack CMakeLists.txt to not include examples dir.
Another thing you may try - set CMAKE_EXE_LINKER_FLAGS to -L/usr/local/include.
This is a perfect situation for creating a FreeBSD port. Since FreeBSD has its own consistent filesystem layout, compiler and linker flags often need to be modified (as noted by arrowdodger) slightly.
The ports system is a framework for persistently capturing those configuration changes and making any software package as easy to install as typing the commands:
cd /usr/ports/category/application-name && make install clean
In a perfect world, you would create the UHD port, submit it for review and addition to the tree. If you need help learning how to do that, the FreeBSD Porter's Handbook and the freebsd-ports mailing list are excellent resources.