My knowledge on Linux is very poor, so don't go too hard on me, please.
I tried to create a bootable CD-ROM(ISO image) from memtest86's source code.
I followed the instruction in user manual, type "make iso", but I got the error message below:
=====================================
make[1]: Leaving directory `/home/chris/src'
./makeiso.sh
make: ./makeiso.sh: Command not found
make: *** [iso] Error 127
=====================================
I have searched error 127, and I found this Make, error 127
I think my path is correct, so is binary a problem?
My system is 64 bits.
The source code can be downloaded here link
Is there a particular reason you want to compile it yourself? You may save some hassle by downloading the prebuilt .iso files. Aside from that, there's a lot of confusion going on here to the point that I'm not sure what's going on. There's memtest86 and memtest86+, which are two different products with a common origin. Some of the references I found to memtest86 are actually for memtest86+, which makes this all the more murky. There's also a memtest86++, which doesn't do much to make my head stop spinning.
Memtest86 has a downloadable .iso image available which includes the source code, and at a quick glance it appears to be the source code you also have so I think this is the one you've got. The Makefile references makeiso.sh, but it isn't included in the source at all. I have no explanation for why this would be or how to resolve it. You might try copying the file from one of the other forked projects, but I couldn't guess whether that will actually work or if there are other files that might be missing as well. I'd suggest you contact their support for help.
Memtest86+ appears to have a much more complete source code repository; for example the makeiso.sh file is included here. If memtest86 isn't working for you, you may wish to consider memtest86+ (I have no idea of the differences between the two or merits of each; I'm just proposing an alternative since the first isn't compiling for you).
In summary, I think your best options are (1) contact support for help, (2) use the prebuilt .iso file instead of compiling yourself, or (3) try an alternative program.
Related
While working for just one month with the MPLABX5.5 + XC32 3.01 I've already had 3 separate instances where code compiled incorrectly, causing my program to fail after either the stack or frame pointer began using an incorrect address. I would like to dump these tools and try something else as tracking down compiler errors is sucking up too much of my time. Is there anything else available that I can use to work with a PIC32MM? Even access to a different compiler than XC32 might help.
I would like to do the same thing. Maybe we can collect the best options for how to get there, as after many many tries, I haven't yet been successful. As one starting point, I'd also like to be able to recompile xc32-gcc from source to understand exactly what it's doing, and to be able to compile xc32 binaries for other architectures (like, as insane as it may sound, I'd like to compile some code for the pic32mm platform with clang or gcc running on a raspberry pi.)
I would love to be able to even just compile xc32-gcc from source. I know this is possible, but I've not been successful. Some links and starts:
https://github.com/zeha/xc32
This seems to be the most recent grouping of source I've found, but I haven't yet figured out how to compile it.
ChipKit is cited a lot, but, I haven't gotten to the bottom of getting that to build for me either. There are numerous projects here, and I'm not sure how they all fit together yet:
https://github.com/chipKIT32
I suspect somebody (maybe someone who will see this post) knows the formula or script or docker file, or whatever to make this simple.
https://gitlab.com/spicastack/pic32-parts-free
This project seems close to what we're talking about, but, the
recommended way to install is with podman and gentoo. I'm not a
gentoo person (yet?), and the docker version failed for me. It's
probably a simple fix to the dockerfile for a gentoo person, but.. I
didn't get there yet. (I did try installing gentoo and started down
the path but holy cow, talk about being down a rabbit hole when what
I'm trying to do is get a pic cross-compiler working.. when emerge on my new gentoo install failed with a python error, I gave up.)
https://github.com/andeha/Twinbeam
This project also says some of the "right things" about building pic32 code using llvm, and has references to llvm2pic32 in this project: https://github.com/andeha/Sprinkle
I've also not yet managed to get this to make viable intel hex files that I can use on a pic just yet, but there's promise.
Use clang/llvm to generate code. I think it will compile C and generate mips out of the box and I've gotten that far, but I can't get it to link and produce a valid hex file yet. The linker scripts from microchip seem sort of ok, but the hex files end up putting the code in the wrong place, I think. I should probably put together a blinky-light example and try to push it farther, and share it with others to figure out what the deal is, but even stepping one step further back and just trying to get a super simple mips assembly program to get linked and be uploadable to a PIC32MM part would be a great success to me.
Maybe others have better references and links?
I am trying to build GridDB from source code on MacOS as recommended How to setup GridDB on macOS with instructions https://docs.griddb.net/gettingstarted/using-source-code/#build-a-server-and-client-java.
During the automake step, I get the following warning(s) for many source files:
3rd_party/MessagePack/Makefile.am:8: warning: source file '$(srcdir)/src/objectc.c' is in a subdirectory,
3rd_party/MessagePack/Makefile.am:8: but option 'subdir-objects' is disabled
Has anyone else had this? Any advice of how to make solve this warning? Is it critical in the make process?
There is a subtle difference between a warning and an error.
Both indicate problems, but while an error indicates a fatal problem that requires a solution right now, a warning is just that: a hint that there's a potential problem.
So: there's no need to solve anything right now.
As a user (of GridDB), you (normally) can ignore any such warning.
However, the maintainers (of GridDB) should look into that, as the warning might turn into an error as the world outside evolves.
Having said that, afaict not using subdir-objects with sources in subdirectories is not a problem per se, and some might prefer it that way. automake tries to push towards subdir-objects, as it fixes problems if you have multiple files with the same name in different directories. However, this (multiple same-named files in different directories) is not the case here.
I've been trying to build a micropython for esp32-camera and I keep getting errors during the make process when building some of the drivers in the mp/ports/esp32/modules directory. The error I get is a syntax error. For example there's a file named ntptime.py in this directory and it contains a single line:
../../esp8266/modules/ntptime.py
and that results in "SyntaxError: invalid syntax"
I've programmed python for a while, but am not familiar with this concept and don't understand how it can work, but maybe it can? I'm not familiar with doing that and since it's not working when I run make, maybe there's something setup-wise that I've missed or whatever. Can anyone shed some light on this practice and explain under what circumstances this works to direct make (or the python compiler) to resolve this statement by loading the source from the directory specified in that single line of code.
Duh, can't believe I missed this: there "files" are symbolic links; I should've remembered that, but alas, I'm getting older by the minute!
Still, it doesn't answer the question as to why they weren't being recognized during make but instead throwing a SyntaxError; but I'll leave that for another day.
I'm trying to build apple's opensource libc (from http://www.opensource.apple.com/source/Libc/Libc-763.11/) on my OS X 10.6.8 laptop. This is in an attempt to essentially get a locally generated replica of /usr/lib/libSystem.B.dylib, which I intend to experiment on further.
I see a couple basic roadblocks though (unless, obviously, I'm missing something basic):
No instructions on how to do the build. There are a couple of Makefiles in the URL I reference above, but they fail to build when I try to do straightforward makes:
$make -f Makefile
Makefile:14: *** missing separator. Stop.
I suspect the source available for download is incomplete. Not incomplete in the sense that Apple isn't revealing all of the changes, but incomplete in the sense that there are source files that were (presumably) not modified by Apple, so isn't included in the collection. For example, I don't see the implementation of the "open" call (which, in the gnu libc hierarchy, is available at io/open.c)
The closest reference I could find after some googling was this: http://www.projectosx.com/forum/index.php?showtopic=1922&st=0&p=12457&#entry12457 but it still isn't close enough for my taste!
Any pointers?
Thanks!
Only some general pointers (although some links are discussing older OSX versions):
http://darwinbuild.macosforge.org/trac/ticket/6
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-projects/darwin/overlay/sys-libs/libc-darwin/libc-darwin-391.ebuild?view=markup&sortby=log
http://althenia.net/wiki/darwin#standard_library_libc
http://dev.gentoo.org/~vapier/CROSS-COMPILE-GUTS
http://www.raccoonfink.com/fink/darwin-cross/
I'm trying to use an external library (wingraph) in a simple program. I have .o and .ppu files. I added the directory that contains them to the list of both "Other Unit Files" and "Include Files" paths under Project->Compiler Options. When building, I still get the error "Can't find unit wingraph used by [program]".
The library is Windows specific and I'm compiling on Windows, too.
What should I do to solve the problem?
Note that I don't have extensive knowledge about Pascal itself nor its tools. I'm just trying to quickly help someone start using the library.
It was the problem of outdated compiler
In future, if this happens make sure any Units used in main units are tagged in the 'uses' section as such:
uses Unit1, Unit2...;