I'm migrating our documentation project from CentOS 5 with Doxygen 1.6.1 to CentOS 7 with Doxygen 1.8.5
The new doxygen version keeps generating index.hhc files (which are intended to be fed to hhc.exe on Windows) which refer to non-existing "axxxxx.html" files.
Is anyone aware of issues which could cause this?
Related
I installed ghcup and:
Stack 2.9.1
HLS 1.8.0
cabal 3.6.2
GHC 9.2.5
All of them are the recommended versions(I verified it using ghcup tui). Then I installed the Haskell extension in VSCode. Unfortunately, it doesn't work. I get syntax highlighting (from the Haskell Syntax Highlighting extension, which seems to be automatically installed alongside the Haskell extension) but there is no Intellisense, no code completion, no error detection and no interactive mode (-->>> evaluation). I experimented with different folders and haskell files. The filetype is correct, because every time I open a .hs file, the Haskell extension checks for updates. I even installed Codium, because I suspected a fault in VSCode, but it was the same there as well.
The hsl language server doesn't seem to be working in Neovim, either. I uninstalled ghcup (ghcup nuke) and reinstalled again. The result is exactly the same. I prepended the PATH and chose vanilla and non-vanilla Stack integration in either installations.
Am I doing something wrong?
OS: Linux Mint on Ubuntu 20.04.1, kernel 5.15.0-56.
After around 10 tries, I managed to fix the problem. It turned out I had three problems:
I had only 12 GB free on my Linux partition, but it seems more are needed. I realised it, when it turned out some haskell-language-server files were missing. I enlarged my Linux partition (something I should have done months ago). The new installation installed all files
The Haskell Language Server HLS was not added to the PATH. I solved it by putting this snippet in ~/.ghcup/config.yaml:
"haskell.serverEnvironment": {
"PATH": "${HOME}/.ghcup/bin:$PATH"
}
The server was now discovered by the Haskell VS Code extension but crashed 5 times and gave up on trying. Restarting it manually didn't help. I opened the logs: View->Output->Haskell and saw the error:
haskell-language-server-wrapper: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by haskell-language-server-wrapper)
It turns out, my Linux Mint distribution uses GLIBC_2.31, not 2.32. This is a very important library, which most applications on the system use. If you are a newbie, it is strongly advised that you DO NOT update it manually.
Instead, what I did, was install a version of the HLS, which used GLIBC_2.31. This problem occured in September and was "fixed" but apparently not very well. There are two options:
download the HLS deb10 version manually (didn't work for me):
ghcup install hls -u https://downloads.haskell.org/~hls/haskell-language-server-1.8.0.0/h
download using ghcup tui HLS version 1.7.0.0 (or whatever newest, which uses your glibc version) and a GHC, which supports that particular version of the HLS (in my case 9.0.2).
I think it's a good idea to preemptively reinstall the extension, in case it used the PATH to configure the HLS, so that its settings are restored to default. It takes up to 20 seconds to initialize the server, so be patient. You can see what's happening in the Output window and verify there are no more errors.
I hope this helps.
I'm currently trying to learn Assembly for x64 Windows. I tried the example code from this Intel website,
but whenever I try to compile it with the command given in the document:
ml64 hello.asm /link /subsystem:windows /defaultlib:kernel32.lib /defaultlib:user32.lib /entry:Start
I always get an
LNK1104 error
I know that it means the compiler can't find the library file, I googled the problem and quickly found that I need Visual Studio with Windows SDK, which I downloaded and installed. But still can't find a kernel32.lib or user32.lib in any files other than the Windows system files.
I tried everything and I simply can't fix it. I hope someone could help figure this out.
There is a well-known MASM32 SDK available created by hutch--. This package contains the requested libraries in a (legacy) 32-bit version.
But there is also a 64-bit update of that famous package by hutch--:
Current build of the 64 bit MASM SDK.
It should contain the .inc and .lib files you need and more...
This is the current build of the 64 bit MASM SDK. This one is a lot closer to complete and with the correct Microsoft binaries added to it, it is capable of building a wide array of application types. It can be use in 2 different ways, it should be unzipped from the root directory of the partition that it is being installed on. You can either manually add it to an installation of the MASM32 SDK OR you can install it on a partition that does not have MASM32 on it and simply rename the buildx64 directory to MASM32. Installing it on another partition is the preferred technique as QE has its menus and accessories set up for building 64 bit code.
You still need to add the Microsoft binaries which would typically be from an installation of vs2017 or from an earlier version for Win7 64. In the bin64 directory there is a file called "Microsoft_File_List.txt" which shows the files you need. The list is from the current version of Visual Studio 2017 version and if this is the version you have, use the ML64 from the "x86_amd64" directory that is 402,584 bytes in size.
In the "buildx64" directory is a batch file called "makeall.bat". This must be run to build all of the libraries and include files.
They are the gold standard of Windows assembly developing.
I have installed, via Composer, the latest versions of PHPUnit and the Skeleton Generator, 4.1.3 and 2.0.1, respectively. I have installed it to my project directory and confirmed that I can test all files. I cannot, however, run the skeleton generator to create new tests. I am using Netbeans and its PHPUnit integration to create the tests. When I attempt to generate the tests, I get the following:
"C:\xampp\php\php.exe" "C:\Users\Bob\Projects\[myProject]\website\vendor\phpunit\phpunit-skeleton-generator\phpunit-skelgen" "--test" "--" "Security\SecureAPI" "C:\Users\Bob\Projects\[myProject]\website\src\Security\SecureAPI.php" "Security\SecureAPITest" "C:\Users\Bob\Projects\[myProject]\website\test\phpunit\src\Security\SecureAPITest.php"
phpunit-skelgen 2.0.1 by Sebastian Bergmann.
[InvalidArgumentException]
Command "Security\SecureAPI" is not defined.
Done.
I had the Netbeans 'Use Bootstrap for Creating New Unit Tests' option selected prior to this, and got this error:
"C:\xampp\php\php.exe" "C:\Users\Bob\Projects\[myProject]\website\vendor\phpunit\phpunit-skeleton-generator\phpunit-skelgen" "--bootstrap" "C:\Users\Bob\Projects\[myProject]\website\test\phpunit\bootstrap.php" "--test" ...
[InvalidArgumentException]
There are no commands defined in the "C" namespace.
Generating tests with version 1.2.1 worked fine on my old development machine. I'm wondering if the issues are specific to version 2.0.1 of the skelgen. It seems to be viewing the C: as a namespace, whereas 1.2.1 did not. I've confirmed that Netbeans produced identical command line instructions for 1.2.1 and 2.0.1, so it appears that the way they are being interpreted has changed.
Has anyone else seen this? Any ideas? I'm running a Win7 machine with Netbeans 8.0. Thanks in advance.
Try to download Dev build of NetBeans from here, the issue with changes in Skeleton Generator 2.x was fixed few days ago
I'm planning to use doxygen to document a project. It's an OSS project whose current documentation is of questionable quality. The reason I've decided to go with doxygen is because from version 1.8, doxygen has added support for Markdown (text formatter; think we use it on this site too).
A concern of mine is for the people who might end up using older versions of Doxygen (for example, it hasn't been updated in the current Ubuntu LTS release).
Is it possible to add some setting or marking in the Doxyfile (doxygen configuration file), such that it will issue an error/warning if someone tries to generate the documentation using an older version of doxygen?
(Ideally, explaining the cause of error as well)
Doxygen itself provides a sort-of warning for these circumstances. If your doxyfile includes things like MARKDOWN_SUPPORT = YES and the incumbent doxygen is not one that supports markdown, then you do get a warning that the option is unrecognised.
Warning: ignoring unsupported tag 'MARKDOWN_SUPPORT'...
Alternatively, you could implement some script that parses the return from doxygen -v which will either return a handy '1.8.5' or the usage help, including a line version 1.y.z - so something based around doxygen -v | grep "1\." would extract a suitable line.
Under Windows 7 x64, when I try to profile an x86 executable with the latest version of Dependency Walker (2.2.6000) the profiling process always hangs at a certain point. Most of the time the last DLL that is loaded is c:\windows\syswow64\URLMON.DLL, so it seems that something inside that DLL is causing a problem. Profiling the same executable on Windows 7 x86 works flawlessly.
I have googled quite extensively, but couldn't come up with a solution to the problem. One suggestion that I found was to uninstall IE 8 or IE 9 and replace it with IE 7, but this doesn't really help. The only effect that I can observe is that with IE 7 the profiling process hangs at a different DLL (iertutil.dll, if I remember correctly, also from the system's syswow64 folder).
So my question is: How can I get Dependency Walker to profile x86 applications on x64 Windows 7? Of course, it would also be nice to know why the problem exists in the first place :-)
Some final notes:
I am using the x86 version of Dependency Walker because I want to profile an x86 executable
Running Dependency Walker as administrator does not help
All profiling options marked as "may fail on WOW64" are disabled
The executable I am currently using as a test case to reproduce the problem is the Sumatra PDF viewer (download link) because it is a simple .exe that does not need installation
Updated instruction based on #Stone Free's comments
The download link you need has changed to:
https://www.microsoft.com/en-us/download/details.aspx?id=42273
Go down to the 2. Install WDK 10 section and select the download:
Locate and run the Wdk setup (wdksetup.exe) from stage 2, then choose the download option rather than install.
Once completed locate and run DownloadLocation\Windows Kits\10\WDK\Installers>"Windows Driver Kit-x86_en-us.msi"
Then you will find Dependency Walker at:
C:\Program Files (x86)\Windows Kits\10\Tools\x64\depends.exe for the 64 bit version
C:\Program Files (x86)\Windows Kits\10\Tools\x86\depends.exe for the 32 bit version
Which is Dependency Walker version 2.2.10011 built 2015-10-29
A handy tool is to use https://github.com/juntalis/depends-launcher which is a simple launcher for Dependency Walker that determines the platform (x86|x64|ia64) of an windows image (dll, exe, etc) and launches the appropriate version of depends.exe to view its dependencies. It's main purpose is for use in a context menu entry to easily view an image's dependencies.
The latest currently known version of Dependency Walker seems to be the 2.2.10011 from 2015-10-29 (links below).
It was deployed with some Windows Development Kit for Windows 10 but the version that it contained is not available anymore from the Microsoft Pages and all the newer Versions does not contain it anymore for unknown reason.
Maybe because also the latest versions have some Problems with the Dynamic-Link Library Redirection or other performance issues. (Using dependency walker under windows 10 seems to be a lot more slow and cumbersome than at previous windows versions - but still great tool for the job)
Following Versions are available:
2.2.10011 (2015-10-29)
unofficial available from this development blog - download at own risk
https://zzz.buzz/2017/05/18/download-dependency-walker/
2.2.9600 (2013-08-22)
available through the WDK 8.1
https://www.microsoft.com/en-us/download/details.aspx?id=42273
after installation present in C:\Program Files (x86)\Windows Kits\10\Tools\[Arch]\depends.exe
2.2.6000 (2006-10-28)
available from official authors website
http://www.dependencywalker.com/
Potential replacement:
For simple tasks the Github project lucasg/Dependencies may be worth to be checked out. But it currently does not support profiling a running app to debug broken runtime dependencies as depends.exe can do.
I've had to switch to using a GitHub project: Dependencies.
As of Windows 10 1809 (10.0.17763) I'm unable to run even depends.exe version 2.2.10011 included in 10.0.10586.0 WDK.
I ran into the same problem and I discovered it is fixed in the latest version of Dependency Walker. I compared 2.2.6000 versus 2.2.8288 and the problem exists in the former but not the latter. However, you will probably have to wait for the Windows 8 WDK to be released to the public in order to get the latest version.