I'm trying to build Premake5 on FreeBSD 10.1 from the sources. I eventually got it to compile by removing the "-dl" option and using gmake explicitly for the build. It built, but I can't get it to do anything but spit out the following error message. Doesn't matter how I invoke it. It crashes even on 'premake5 --help'.
Here's the message:
PANIC: unprotected error in call to Lua API (attempt to call a string value)
The code is buggy as all get-out. It starts by assuming linux is posix which is clearly not the case. They use linuxism all over the place so converting to posix is going to be quite a task, and until that is done it will never work satisfactorily on non-linux posix based systems.
The -ldl was obviously the first stumbling block. The next is in the function premake_locate_executable in premake.c. In this they are using the /proc filesystem which is a linuxism and since this fails on BSD they are falling back to some lua methods but they seem to be assuming that lua_tostring pops the corresponding value which it doesn't. Since their stack isn't balanced in this function the following lua_call is trying to call the garbage they've left on the stack rather than the function they intended.
Even after I fixed this issue they use getconf _NPROCESSORS_ONLN to get the number of cores to multi-job the make build but they don't actually check that this call succeeds (which it doesn't outside of Linux and MacOSX).
After fixing this issue I then ran into the problem that their makefiles aren't regular make, but GNU-make, so I had to change to using gmake to try and build.
From that point it just came unravelled because none of the premake files in the contrib directory are configured for BSD despite it being one of the legal configuration targets (i.e. it doesn't default to linux) and so there is no configuration for those components.
TLDR: BSD is not a supported platform
Related
I am trying to use the Dafny-to-Python compiler that is suggested in Dafny's reference (25.7.7): http://dafny.org/dafny/DafnyRef/DafnyRef.html#2577-python
However, I cannot run the first step for it in the terminal: dafny build --target:py A.dfy, since I get the error: Dafny: Error: unknown switch: --target. I use Use /help for available options as they suggest, but have no idea on how to solve.
Just in case, I also attempted using the old version of the command (see 25.8.11. in the same reference): dafny Hello.dfy -compileTarget:py but then got message Dafny: Error: Invalid argument "py" to option compileTarget.
Any idea? Note that the authors themselves clearly state that The Dafny-to-Python compiler is still under development.
PS: I usually use Dafny in Visual Studio and not in the terminal, so maybe I lack some kind of library or something.
Neither the new CLI nor the Python compiler are supported by the very outdated version of Dafny you are using. You are presumably not using the correct VS Code extension, so I would start there. As of today, this should install 3.10.0 at /Users/$USER/.vscode/extensions/dafny-lang.ide-vscode-3.0.3/out/resources/3.10.0/github/dafny/Dafny.dll. To see how to use the dll, try hitting F5 with a Dafny file opened in VS Code. The Python compiler is complete and passes all tests these days.
I am trying to build a clang static checker that will help me identify path(s) to a line in code where variables of type "struct in_addr" (on linux) are being modified in C/C++ progrmas. So I started to build a tool that will find lines where "struct in_addr" variable are being modified (and will then attempt to trace path to such places). For my first step I felt I only need to work with AST, I would work w/ paths as step 2.
I started with the "LoopConvert" example. I understand it and am making some progress, but I can't find how to only make the "LoopConvert" example in he cmake|build eco system. I had used
cmake -DCMAKE_BUILD_TYPE=Debug -G "Unix Makefiles"
when I started. I find that when I edit my example and rebuild (by typing "make" in the build directory) the build systems checks everything, seems to rebuilding quite a bit though nothing else has changed but 1 line in LoopConvert.cpp, and takes forever.
How can only rebuild the one tool I am working on? If I can shorten my edit-compile-test cycle I feel I can learn more quickly.
In a comment you say that switching to Ninja helped. I'll add my advice when using make.
First, as explained in an answer to Building clang taking forever, when invoking cmake, pass -DCMAKE_BUILD_TYPE=Release instead of -DCMAKE_BUILD_TYPE=Debug. The "debug" build type produces an enormous clang executable (2.2 GB) whereas "release" produces a more reasonable size (150 MB). The large size causes the linker to spend a long time and consume a lot of memory (of order 10 GB?), possibly leading to swapping (it did on my 16 GB VM).
Second, and this more directly addresses the excessive recompilation, what I do is save the original output of make VERBOSE=1 to a file, then copy the command lines that are actually relevant to what I am changing (compile, archive, link) into a little shell script that I run thereafter. This is of course fragile, but IMO the substantially increased speed is worth it during my edit-compile-debug inner loop.
I have not tried Ninja yet, but have no reason to doubt your claim that it works much better. Although, again, I think you want build type to be release for faster link time.
I was trying to run a simple pthread program on x86 SE mode.
Are m5threads the only way to do this?
When I try to compile libpthread using make I get the below error:
pthread.c:40:2: error: #error "spinlock routines not available for your arch!\n"
Is there something I am missing? Maybe some missing path variable or some minor modification of the code somewhere. Because I have the files spinlock_x86.h and tls_defs.h.
No, you don't have to use m5threads if you're simulating x86 on an x86 host. gem5 has support for running code in shared libraries on the host. Thus, you should be able to compile your program with "-lpthread" and simply run it on gem5.
You may need to mess around with the runscript to get things to work. IIRC, you need to have the exact number of CPUs as threads and set the workload to the same binary for each CPU.
I'm producing builds using MSBuild, and build configurations set up in the dproj on the command line. It's slightly disconcerting that the size of the executables thus produced are different (not by much, but still!) to what an IDE build produces. Any ideas why? I would have thought the same compiler is used?
The main power of building from the Delphi command-line compiler is standardization - you explicitly identify the options (on the command line, in the .cfg files, etc), and the compiler follows the options provided exclusively. In contrast, the IDE has many other behaviors that are not clear and explicit - for example, it may search library paths not specified in the Project Options. My guess is that something's happening in the IDE build of which you're not entirely aware - and this is why standardized builds are done from the command line.
To see what IDE is doind, check
Tools | Options | Environment Options | Compiling and Running | Show Command Line
And you can check the compiler messages.
The first answer on using the command line for build consistency is right on and it is probably something you needn't worry about if you are relying on a build system where production files are always sourced from the console builds.
On the other hand, if you really do want to figure out what is going on you should turn on map files (at the full detail level) and compare/diff them. If there are differences between the two they will show up there. Any other differences that may exist are likely a result of a commmand line option being different (such as a conditional flag that may be set in the IDE settings).
This behavior has existed in every version of Delphi I've used. (5 - 2006). I wouldn't worry to much about it. When I first discovered it I spent a lot of time trying to resolve the difference. Did I miss a compiler flag? Is there a discrepancy between the IDE and the command line compiler's supported options?
In the end I decided it wasn't that big of an issue. Both consistently produced functionally equivalent executables.
If you supply exactly the same params to the command line compiler the produced executables will virtually be identical.
In fact the IDE just calls the commandline compiler. Compile your project in the IDE and look at the messages window. you will see the full dcc32.exe call ...
My problem is to create an ant target for automating our installer running in console mode.
The installer is created using InstallAnywhere 2008, which UniversalExtractor recognizes as a 7-zip archive. Once I have the archive unpacked, it appears that the task can use an input file to drive the console (at the very least, it appears that emitting a quit shuts everything down correctly, and output is captured).
So it looks to me as though I have all of the pieces I need for proving out this idea except a clean way to perform-self-extraction-then-stop. Searching for a command-line argument to stop the auto execution has not produced a likely candidate, and the only suitable ant task I've found ( http://www.pharmasoft.be/7z/ ) isn't so clearly documented that I have a lot of confidence in it.
The completed completed is expected to work in Windows, Linux, and a small handful of other Unix environments.
What's the best practice to use here?
Since you control the installer creation, can you run the self-extraction step on your machine, package the results before the installer is launched in a ZIP file, etc. and use that instead of the single file executable? Not very elegant but it may work.
Also, I am a bit hesitant to blatantly promote my project :) but since it has been a while since you asked the question and nobody has answered, have you considered an alternative? Our project InstallBuilder allows you to install in unattended mode directly, without having to autoextract the contents. Just invoke the executable with --mode unattended, pass any additional options you may need from the command line or an external file and you are good to go. We have a lot of ex-InstallAnywhere customers :)