Error when compiling nettle-2.7.1 - gmp

When I try to compile nettle-2.7.1, I get the following:
root#tcx2270-19:~/nettle-2.7.1# make
make: Warning: Can't find aes-decrypt-internal.o.d': No such file or directory
make: Fatal error in reader: Makefile, line 594: Read of include fileaes-decrypt-internal.o.d' failed
Has anyone seen this issue? Thanks.

I also had the exact same problem. It has nothing to do with gmp. The ./configure script generates a broken Makefile. After doing some analyzation of the generated Makefile I figured out a solution.
On the very bottom of the generated Makefile search for the line that looks like the following:
DEP_FILES = $(SOURCES:.c=.$(OBJEXT).d) $(SOURCES:.c=.p$(OBJEXT).d) asm.d
You can fix the build by changing it to the following line:
DEP_FILES = $(SOURCES:.c=.c.$(OBJEXT).d) $(SOURCES:.c=.c.p$(OBJEXT).d) asm.d
Additionally, we have to fix the Makefiles in all sub-directories.
For ./tools/Makefile, on the very bottom, find the line that looks like:
include $(SOURCES:.c=.$(OBJEXT).d)
and change it to
include $(SOURCES:.c=.c.$(OBJEXT).d)
Furthermore, you need to add the following two build-targets:
../libnettle.a:
$(MAKE) -C .. libnettle.a
../libhogweed.a:
$(MAKE) -C .. libhogweed.a
For ./testsuite/Makefile, on the very bottom, find the line that looks like this:
DEP_FILES = $(SOURCES:.c=.$(OBJEXT).d) $(CXX_SOURCES:.cxx=.$(OBJEXT).d)
and change it to:
DEP_FILES = $(SOURCES:.c=.c.$(OBJEXT).d) $(CXX_SOURCES:.cxx=.cxx.$(OBJEXT).d)
Finally, in ./examples/Makefile, again on the very bottom, search for the line that looks like:
include $(SOURCES:.c=.$(OBJEXT).d)
and change it to
include $(SOURCES:.c=.c.$(OBJEXT).d)
Phew, at least for me, that makes the build work. Of course, this is an ugly solution but it gets the job done. A better solution would be to fix the configure-script but I did not have the time to do it yet. It is also worth noting that nettle 3.0 does not have this issue. Too bad gnutls does not work with that newer version.

UPDATE: I created a patch which does all the above fixes in the Makefile.in files. As a result, you don't have to fix them yourselfs. Optimally, just unpack the source, apply the patch and proceed the way you normally would by continuing with the ./configure.
Get it from here: http://pastebin.com/36M5LHK3

Related

undefined reference to `zgesvd_' - BLAS issues in C compilation

I am having an issue with the LAPACK/BLAS libraries when compiling a C code that needs them.
The issues are, when I run "make", I get:
file.c:(.text+0x1c41): undefined reference to `zgesvd_'
file.c:(.text+0x1c9c): undefined reference to `zgetrf_'
../file.a(SpatialOrientation.o): In function `myfunction.c':myfunction.c:(.text+0x7be): undefined reference to `dsyev_'
And several other such lines, all referring to similar missing references.
I have chased this error down to being something to do with BLAS. I followed the directions given at this excellent link for installing BLAS and put the relevant directory on the path. I also changed my Makefile accordingly to find these libraries.
Any help on this issue would be really appreciated!
Just to update, I recently installed itpp as well, also following the instructional here, since it seemed my missing references were linked to that. No changes so far...
Thanks for your help!
The problem is solved! Hooray! I just danced around my office...
For those who have the same problem, here is what I did:
1) Follow the instructions given here to make the lapack and blas libraries. To paraphrase, for a scientific Linux 6 machine, they are:
wget http://www.netlib.org/lapack/lapack.tgz
tar xvzf lapack.tgz
cd lapack-3.3.0 //if version number changes, change here to the right directory
mv make.inc.example make.inc
2) Then (important bit, also recommended here):
edit make.inc and add -m64 -fPIC flag to fortran compiler options: FORTRAN, OPTS, NOOPT, LOADER
Then
make blaslib
make
Now, what you have is, in /lapack-3.6.1 (or whatever your directory is called after this process), two files:
librefblas.a , and liblapack.a.
3) The next thing I did was to copy librefblas.a and liblapack.a into some subdirectories - i.e. /lib/liblapack for liblapack.a and /lib/libblas for librefblas.a
4) Then, put those directories in your makefile, like this:
LIBDIR1 = /path/lib/lapack
LIBDIR2 = /path/lib/blas
LIBS = -L$(LIBDIR1) -llapack -L$(LIBDIR2) -lblas $(SYSLIBS)
LIBSMPI = -L$(LIBDIR1) -llapack -L$(LIBDIR2) -lblas $(MPILIBS) $(SYSLIBS)
I also added /path/lib/lapack and /path/lib/blas onto my LD_LIBRARY_PATH (and PATH, just-in-case...)
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/lib/lapack:/path/lib/blas
export PATH=$PATH:/path/lib/lapack:/path/lib/blas
Then, go to wherever you Makefile is, and type
make
Yay yay yay!
By the way, with the latest version of lapack and blas, obtained in step 1), I compiled with gcc version 5.1.0 and the corresponding mpicc (openmpi 1.10.2).
Hope this helps someone else and shares the absolute delight.

Running a python script as part of a cmake build

I'm using cmake for the first time and am just not having luck finding examples that help me figure out what I'm doing wrong. The functionality seems very basic, but nothing I've tried thus far has given me any meaningful output or error.
I have a PRELOAD command for a document, and this works fine as long as the document has already been created.
set(variable_name
PRELOAD ${_source_directory}/Documents/output.txt AS output.txt
)
But I want the document generation(which is accomplished via a python script) to be part of the cmake build process as well. The command I want to run is
python_script.py ${_source_directory}/Documents/input.txt
${_source_directory}/Documents/output.txt
and I want that to run before the PRELOAD statement is executed.
Here's an example of what I've tried
add_custom_command(
OUTPUT ${_source_directory}/Documents/output.txt
COMMAND python_script.py ${_source_directory}/Documents/input.txt
${_source_directory}/Documents/output.txt
)
set(variable_name
PRELOAD ${_source_directory}/Documents/output.txt AS output.txt
)
But that gives me the same error as if the add_custom_command wasn't even there ("No rule to make target ${_source_directory}/Documents/output.txt").
You do/understand it wrong. As it was mentioned in comments set() has nothing like PRELOAD.
The correct way is to use add_custom_target() which would produce an output.txt in desired directory and then add_dependencies() for target you want to build and which would use the output.txt.

How to use the program's exit status at compile time?

This question is subsequent to my previous one: How to integrate such kind of source generator into CMake build chain?
Currently, the C source file is generated from XS in this way:
set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/${file_src_by_xs} PROPERTIES GENERATED 1)
add_custom_target(${file_src_by_xs}
COMMAND ${XSUBPP_EXECUTABLE} ${XSUBPP_EXTRA_OPTIONS} ${lang_args} ${typemap_args} ${file_xs} >${CMAKE_CURRENT_BINARY_DIR}/${file_src_by_xs}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
DEPENDS ${file_xs} ${files_xsh} ${_XSUBPP_TYPEMAP_FILES}
COMMENT "generating source from XS file ${file_xs}"
)
The GENERATED property let cmake don't check the existence of this source file at configure time, and add_custom_target let the xsubpp always re-run at each compile. The reason for always rerun is because xsubpp will generate an incomplete source file even if it fails, so there are possibility that the whole compiling continues with an incomplete source file.
I found it is time consuming to always re-run source generator and recompile it. So I want to have it re-run only when dependent XS files are modified. However, if I do so, the incomplete generated source file must be deleted.
So my question is: is there any way to remove the generated file, only when the program exit abnormally at compile time?
Or more generic: is there any way to run a command depending on another command's exit status at compile time?
You can always write a wrapper script in your favorite language, e.g. Perl or Ruby, that runs xsubpp and deletes the output file if the command failed. That way you can be sure that if it exists, it is correct.
In addition, I would suggest that you use the OUTPUT keyword of add_custom_command to tell CMake that the file is a result of executing the command. (And, if you do that, you don't have to set the GENERATED property manually.)
Inspired by #Lindydancer's answer, I achieved the purpose by multiple COMMANDs in one target, and it don't need to write an external wrapper script.
set(source_file_ok ${source_file}.ok)
add_custom_command(
OUTPUT ${source_file} ${source_file_ok}
DEPENDS ${xs_file} ${xsh_files}
COMMAND rm -f ${source_file_ok}
COMMAND xsubpp ...... >${source_file}
COMMAND touch ${source_file_ok}
)
add_library(${xs_lib} ${source_file})
add_dependencies(${xs_lib} ${source_file} ${source_file_ok})
The custom target has 3 commands. The OK file only exists when xsubpp is success, and this file is added as a dependency of the library. When xsubpp is not success, the dependency on the OK file will force the custom command to be run again.
The only flaw is cross-platform: not all OS have touch and rm, so the name of these two commands should be decided according to OS type.

How to include .iuml path to generate PlantUML diagram in Doxygen

I'm working on the documentation of a component using Doxygen and I want to include UMLdiagrams in between the text.
I know how to do most of it, as I simply need to copy the .tuml source into my .dox file and run doxygen. However, one of my diagrams is a class diagram that includes other .iuml files, like explained in the PlantUML site.
So, basically, I do:
#mainpage main_page MyDoxygen
\
...
\
#startuml
\
!include iuml_files/Class01.iuml
!include iuml_files/Class02.iuml
\
MainClass <|-- Class01
MainClass <|-- Class02
\
#enduml
Long story short, I don't know how to make Doxygen understand it must look for the .iuml files in the directory (relative path) I'm giving as argument to the include directive.
If I wasn't clear enough as to what I need, please let me know and I will try make it clearer.
Can I please get some help?
I had a similar problem (I own the Word Add-in for plantuml)
You can specify the java property "plantuml.include.path" in the command line :
java -Dplantuml.include.path="c:/mydir" -jar plantuml.jar atest1.txt
(see http://plantuml.sourceforge.net/preprocessing.html)
I expect it'll work when you modify the batch file for calling Plantuml
http://plantuml.sourceforge.net/doxygen.html
I had a similar request for my Word Addin for Plantuml and here it worked.
The Real Answer
Use the PLANTUML_INCLUDE_PATH = ./someRelativeDir configuration, visible in the Doxygen wizard's DOT panel.
The include path is relative to your Doxygen config, ie the starting directory from which the doxygen config is taken.
A Red Herring
I'm leaving the rest of this answer here in case anyone found it previously.
I wrongly reported a bug because I needed new reading glasses and didn't notice a stray character in my path.
This was resolved as not a Doxygen bug
For any interested parties, this is what I saw.
Running PlantUML on generated file /Users/andydent/dev/touchgramdesign/doxygeneratedTG4IM/html/inline_umlgraph_1.pu
Preprocessor Error: Cannot include /Users/andydent/dev/touchgramdesign/doxygeneratedTG4IM/html/handDrawnStyle.iuml
Error line 2 in file: /Users/andydent/dev/touchgramdesign/doxygeneratedTG4IM/html/inline_umlgraph_1.pu
Some diagram description contains errors
error: Problems running PlantUML. Verify that the command 'java -jar "/Library/Java/Extensions/plantuml.jar" -h' works from the command line. Exit code: 1
This is using the configuration setting
PLANTUML_INCLUDE_PATH = ./iumltToCopy
Sharper eyes than mine (at the time) noticed the extra character in the path iuml t ToCopy

Using WinMerge with Bazaar

I searched a lot, found that some people claimed they did that, but I can't make it to work.
How to you use WinMerge, my favorite diff tool on Windows, with Bazaar?
I know difftools plugin (shipped with Bazaar) handles this but the controller.py file doesn't list it, and I fail to see where to specify a path. Looks like it searches in PATH variable, and reports bzr: ERROR: Cannot find 'winmerge' in (long list of paths).
I tried to put a .cmd file, then a shortcut to WinMergeU.exe in Bazaar's directory, renaming accordingly (winmerge.cmd, winmerge.lnk) the register_diff_tool parameter. No more error, but nothing is launched...
So, does somebody has any success using WinMerge (or perhaps some other Windows tool) with Bazaar?
I would be interested to use it with extmerge plugin too...
EDIT After the first two answers, I tried some variants which I list here for reference. None worked:
# As suggested:
# Bad: bzr: ERROR: [Errno 22] Invalid argument: 'c:\\docume~1\\philho\\locals~1\\temp\\bzr_C:/Program Files/_Text/WinMerge/WinMergeU.exeh7angm.log'
wdiff = diff --using "C:/Program Files/_Text/WinMerge/WinMergeU.exe"
# Bad: bzr: ERROR: Cannot find 'C:Progra~1_TextWinMergeWinMergeU.exe' in <PATH>
wdiff = diff --using C:\Progra~1\_Text\WinMerge\WinMergeU.exe
# Variants:
# Bad: bzr: ERROR: [Errno 22] Invalid argument: 'c:\\docume~1\\philho\\locals~1\\temp\\bzr_C:/Progra~1/_Text/WinMerge/WinMergeU.exejuttft.log'
wdiff = diff --using C:/Progra~1/_Text/WinMerge/WinMergeU.exe
# Bad: bzr: ERROR: [Errno 22] Invalid argument: 'c:\\docume~1\\philho\\locals~1\\temp\\bzr_C:\\Program Files\\_Text\\WinMerge\\WinMergeU.exehpabjl.log'
wdiff = diff --using "C:\\Program Files\\_Text\\WinMerge\\WinMergeU.exe"
# Bad: bzr: ERROR: [Errno 22] Invalid argument: 'c:\\docume~1\\philho\\locals~1\\temp\\bzr_C:\\Progra~1\\_Text\\WinMerge\\WinMergeU.exe4gi5or.log'
wdiff = diff --using C:\\Progra~1\\_Text\\WinMerge\\WinMergeU.exe
Using:
Bazaar (bzr) 1.11
Python interpreter: C:\Program Files\_Dev\Bazaar\python25.dll 2.5.2
Actually, the awful (and embarrassing) truth is that it appears that one of my earlier attempts worked, but I saw nothing... because I was testing against a committed file! I suppose I was expecting that by default it compared last two revisions or something.
Anyway, as I wrote in a comment, I don't want to put WinMerge directory in my already too long path, so I took at middle road, making a command file and putting it in Bazaar's directory which is already in the path.
At least it works, and I can easily add parameters if needed.
[ALIASES]
wdiff = diff --using winmerge.cmd
# winmerge.cmd contains:
"C:\Program Files\_Text\WinMerge\WinMergeU.exe" %1 %2
Maybe I should put that as solution in the thread, although it lacks elegance.
For the record, while we are on the topic of external tools, I also added to bazaar.conf:
editor = C:/Program Files/_Text/SciTE/SciTE.exe
It is used by commit (without -m option), for example.
Next step: extmerge. Looking closer, it doesn't seem WinMerge is usable there, not having 3-way merge. I might use Perforce's merge, it is free and I am used to it.
Just a note for those as confused as me: extmerge isn't a GUI replacement for merge. If you run it, it will report no conflict, even if merge reports them. Actually, you have to run merge first, then extmerge to use the generated/altered files and do the job...
If you want to use WinMerge anyway, perhaps to compare OTHER to THIS, you can use:
external_merge = "C:/Program Files/_Text/WinMerge/WinMergeU.exe %o %t %r"
I hope my attempts/remarks here will be useful to some other people... :-)
[UPDATE]
Oookaaay!
So I was confused! A message in the Bazaar mailing list enlightened my poor soul:
"You know that bzr also provides diff --using, right? You prefer the version in difftools?" -- Aaron Bentley, 2009-04-03 in Re: difftools, ‘bzr diff --using footool’, and ‘diffuse’
Aargh! No, I didn't know that.
I removed difftools plugin, edited my line to:
wdiff = diff --using "C:/Program Files/_Text/WinMerge/WinMergeU.exe"
and it worked perfectly fine, out of the box! I am not sure why this difftools plugin isn't marked as obsolete.
I leave this question as a reference in case other newbies like me are confused too. And I can at least elect an answer. Thanks!
bzr diff --using "C:/Program Files/WinMerge/WinMergeU.exe"
You can add this to aliases in bazaar.conf
Or, if you have C:\Program Files\WinMerge in your PATH environment variable you can use it as:
bzr diff --using WinMergeU.exe
Did you read the README file that came with the difftools plugin? It explained the --using option.
Also, going by bazaar installed on my windows machine, which hasn't been updated in a while, you'll find your config file in C:\Documents and Settings\username\Application Data\bazaar\2.0\bazaar.conf
Add the following under the [ALIASES] section (adding that section if it doesn't exist):
[ALIASES]
gdiff = diff --using C:\Progra~1\WinMerge\WinMergeU.exe
Change the path to suit your installation. Then you can just go
bazaar gdiff
instead of
bazaar diff
This seemed to work for me:
bzr diff --using "C:\\program files\\winmerge\\winmergeu.exe"
As an aside, if you can't get it working, I would suggest using the q* UI tools, like:
bzr qdiff
bzr qlog
bzr qcommit
..etc
The Tortoise Bazaar->Settings->General Bazaar Options->Diff->Add not works for me. I try to use the answers above, but unfortunately they not works too. But I used the answers for a base, and I find a solution. I edited the
C:\Documents and Settings\*username*\Application Data\bazaar\2.0\qbazaar.conf (not bazaar.conf)
and added the line
[EXTDIFF]
WinMerge = "C:/Program Files/TC UP/PLUGINS/Media/WinMerge/WinMergeU.exe"
It works fine, and I can choose between the builtin diff and the WinMerge.