When I run the config file for installing GSL library for Windows 10 I get the following error:
error: Something went wrong bootstrapping makefile fragments for
automatic dependency tracking. If GNU make was not used, consider
re-running the configure script with MAKE="gmake" (or whatever is
necessary). You can also try re-running configure with the
'--disable-dependency-tracking' option to at least be able to build
the package (albeit without support for automatic dependency
tracking).
If I run ./config MAKE="gmake" I still get the error. I have searched in StackOverflow and on the web and still haven't found a solution.
Related
Installing Idris on Windows 10 using instructions to:
Install Haskell following this
Replaced , with ; in multiline paths of config files as reported by #gergelybat in this
c:\Users\me\cabal update
c:\Users\me\cabal install idris
Several dependency errors arise, I follow Idris' instructions to apply with blind faith the following further flags
----reinstall
--avoid-reinstalls
--force-reinstalls
--upgrade-dependencies
Progress is made things begin to be built, we get all the way to building a temp directory with something called idris-1.3.1\…\setup.exe
Then we crash with following error:
C:\Users\me\AppData\Local\Temp\cabal-tmp-26128\idris-1.3.1\dist\setup: removeDirectoryRecursive:
…": unsatisfied constraints (The directory is not empty.)
Googling this I find this same error happens across cabal installs and logged as issues on oodles of GitHub projects. Theories are all over the map and no solutions provided. The Haskell documentation on removeDirectoryRecursive offers a clue ending with the remark that this fails on Windows if the directory is a symbolic-link.
How does one get past this problem to finish an install?
This is mostly to record the steps that worked, thanks to Michael Sonyman for the major tip.
Steps to follow.
Install Haskell (with Stack) following this
Replace , with ; in multiline paths of config files as reported by #gergelybat in this
Check that you have a version of make by checking stack exec -- which make
if you get no make then install GnuWin32,
ensure that the install directory for (e.g. c:\Program Files (x86)\GnuWin32\bin is added to your system path (follow "set environment variables").
Restart PowerShell/Command prompt, retry step 3, you should see a make found, if not recheck your steps.
Run stack install --resolver lts-12.26 idris … this may be very slow. It ends by copying the Idris compiler and other items to C:\Users\you\AppData\Roaming\local\bin:
Test by typing idris at prompt, it should load the Idris REPL.
Enjoy dependent typing for the rest of your programming life.
You could try using cabal new-build or cabal new-install, but I am not sure if that will work.
This post summarize my painful but finally successful (just by chance) way to build own conda package for the
netgen meshing tool with Python interface. I found the recipe for the netgen build due to tpaviot.
After cloning the repository into 'netgen-conda' folder I ran:
conda build netgen-conda/netgen-6.2-dev
Which reports "Unsatisfiable dependencies": 'oce', 'gcc-5', 'binutils'.
So I tried to install these packages myself. Unfortunately the documentation do not emphasize the important fact that 'conda build' use its own temporary environment so it doesn't matter what you have installed (see). Nevertheless even installing 'gcc-5' together with 'binutils' manually turns out to be nearly impossible.
Hint for other newbies: Lot of my problems disappear after I learned details about channels.
First try was installing 'gcc-5' with 'binutils' from the 'salford_systems' channel suggested by anaconda:
conda install -c salford_systems binutils gcc-5
But it results in:
ERROR conda.core.link:_execute_actions(337): An error occurred while installing package 'salford_systems::gcc-5-5.3.0-0'.
LinkError: post-link script failed for package salford_systems::gcc-5-5.3.0-0
running your command again with-vwill provide additional information
location of failed script: /home/jb/miniconda3/envs/test/bin/.gcc-5-post-link.sh
Using verbose output ('-v') provides no more info. I was also confused by the fact that the script does not exist on the given path (probably automatically deleted).
With current experience I admit that the reason of problem can be dug out from the '-vv' output (reported issue). After some trying I found that only way to
install both is to first install 'gcc-5' into a clean environment and then install 'binutils'. Since 'conda build' installs everything
from scratch and there is no way to specify order of installed packages I was stuck.
Another issue that puzzled me is the 'conda build' long prefix hack. For unknown reason they use extremely long prefix for an auxiliary folder
which result in various kind of issues. I have faced to three such problems:
As is usual today, I have encrypted HOME causing a known issue.
Using a workaround '--croot /tmp' prevents creating the hard links from '/tmp' into 'HOME/miniconda3' since they are on different filesystems.
There is a fallback to use the copy. I even thought that the fallback doesn't work for a while, but it worked, just making the build running longer.
Trying to install 'gcc' (4.x) from 'default' channel complained about too short prefix. So ultimate workaroud was to set the length of the prefix manually
'--prefix-length 70'.
Finally, I found that the dependency on 'binutils' is not necessary and successfully build the package with:
conda build --prefix-length 70 -c salford_systems -c conda-forge -c dlr-sc netgen-conda/netgen-6.2-dev
Summary (of open questions):
Conda channels introduce a new kind of dependency hell already forgotten when using 'apt-get'. Is there a way to figure out what is a canonical channel for a package.
Does anyone succeed to build with combination 'gcc-5' and 'binutils'?
There is still lack of documentation about internal conda mechanisms and error messages do not provide clue to the problem.
Conda-build use a problematic prefix hack and lack ability to control order of installed packages. Does anybody know the reason for this hack?
I'm trying to compile geany-plugins-1.28. The debugger plugin (the only one I need) gives the error:
debug.c:53:21: fatal error: vte/vte.h: No such file or directory
#include <vte/vte.h>
Clearly it needs to know where this file is located to compile. I found the vte.h file in the src directory of the main program geany-1.28. When running
sudo ./configure cflags=-I/home/pi/Desktop/geany-1.28/src
I get the same error about the missing header later trying to compile the debugger plugin.
I ran
./configure --help
to get all the flag options. The output is here
How do I get this to configure correctly so that it compiles. I need to compile the debugger version 1.28 myself because apt only installs 1.24 which I think has a bug because it crashes when I run my code with the error:
close failed in file object destructor:
sys.execpthook is missing
lost sys.stderr
CFLAGS is case-sensitive environment variable, so you should set it before running configure, not try to pass it as a command line argument. This variant:
$ export CFLAGS=-I/home/pi/Desktop/geany-1.28/src
$ ./configure
leaves CFLAGS set for current shell until you leave it. While this:
$ CFLAGS=-I/home/pi/Desktop/geany-1.28/src ./configure
sets variable only for current command, i.e. configure.
Some other issues:
You do not need sudo to configure and make. It is also unnecessary for make install if you set PREFIX to a path you have privileges to write to.
Does plugin's build system also builds all it's dependencies? If not, you may face linker errors a bit later.
Update:
I have tried to build debugger plugin and got rid of your error. It seems that vte.h coming with Geany is it's intrinsic, while the plugin requires full-featured file from the library. So I just installed vte and vte-devel from repos. Nevertheless, I got some other unrelated errors coming from Glib. I will not continue my attempts to build all this right now. Hope my effort will be helpful at least a little.
As in this answer stated, vte.h is not the file you are looking for. Install libvte(-dev) package on your system and rerun configure.
Just for the record: vte.h on Geany is a dummy to allow Geany to kind of dynamical enable vte or disable it depending on vte is installed on the system or not.
I am currently trying to run Coverity Prevent and I believe I have everything set up appropriately on my windows 7 build machine. I have run it with AnthillPro and when my code finishes and gets to Coverity it says that everything was built fine and the only error I get is:
Warning: Cygwin pathname conversion ignored; no applicable
'bash'/'mount', 'cygpath', or registry keys found.
I have even tried to install Cygwin to see if this could rectify the problem and I still end up with the same error.
I am currently using AnthillPro 3.7 and Coverity 5.5.3. The build log says that I have warnings but no errors and that it hasn't emitted anything. I have tried to run a script directly from the machine (not server) itself and I have the same error as I do using the Coverity Prevent in Anthill
This is the only information I get at the bottom of the build log.
Run from AnthillPro:
Build time (cov-build overall): 00:00:17.753597
[WARNING] No files were emitted. This may be due to a problem with your configuration
or because no files were actually compiled by your build command.
Please make sure you have configured the compilers actually used in the compilation.
For more details, please look at:
d:\Coverity\Intermediate\AllToolsProjects.sln_pc_vs2010\build-log.txt
Run from Script:
The cov-build FAILED.
This may be because less than 90 percent of units were successfully compiled
Check for errors here:
D:\\Coverity\Scripts\build_AllToolsProjects.sln_pc_vs2010.bat
D:\\Coverity\Intermediate\AllToolsProjects.sln_pc_vs2010\build-log.txt
D:\\Coverity\Configuration\pc_vs2010
It sounds like you haven't configured the compiler - that's when you tell your Coverity Analysis installation which compiler you are using. devenv is not a compiler, cl.exe is.
Run the following command:
coverity-analysis-dir/bin/cov-configure --msvc
This will say that you are using the cl.exe compiler and it's of type msvc no matter where it's installed.
Then rerun your Coverity build and see if it captures more of your compilations.
I'm trying to modify GTK2 on Ubuntu Oneiric.
I download the source:
apt-get source libgtk2.0-0
cd gtk+2.0-2.24.6/
I try to compile and overwrite the current GTK2:
./configure --prefix=/usr
sudo make
Soemhow I get an error (I have all the necessary libraries and the build-essential package etc):
In file included from gtkquery.c:26:0:
gtkquery.h:31:2: error: #error "gtkfilechooserprivate.h is not supported API for general use"
By the way, I am able to modify and recompile GTK3 with no problems with the same steps.
If use debuild, I get thousands of
dpkg-source: error: cannot represent change to gtk+2.3.0-2.24.6/gtk+2.0-2.24.6/something: binary file contents changed
You won't get anything near the Ubuntu-provided build if you try building it by hand that way -- you'll miss all the ./configure options and other settings. (Look into debian/rules for the full details of what they're setting.)
Instead, try debian/rules build.
For reasons I haven't investigated yet (possibly including me not understanding how it should work), that didn't work on the first package I tried, but setting up pbuilder let me build the package I wanted.
It might feel like overkill to get a clean chroot as a build environment, but it is way too easy to build yourself problems that no one else in the world can replicate because you've got something funny on your local system.