While building our project on the Build Server, the compilation fails with the error message:
TlbImp: error TI0000 : The input file 'C:\*.dll' is not a valid type library.
We tried to manually invoke the TlbImp command thru the VS2005 Command Prompt and the same error message appeared.
To investigate, we tried to create a clean build environment in a Virtual Machine (Vbox), then we run the build there. It went fine.
We also tried to invoke the same TlbImp command thru the VS2005 Command Prompt and it succeeded.
With that, we are assuming that there is nothing wrong with the DLL. Do you have any idea what scenario(s) can cause this problem?
EDIT:
Found the problem, see my answer. ;)
If it is working on one machine and not on the other, then most probably some dependency of this DLL is missing in your machine. Inspect the dll through DependencyWalker and you will get to know that which dependency hasn't been built properly.
After closer inspection, we found out that the environment variables on the official build server is FUBAR.
The official build server was installed with both VS2003 and VS2005. Our project is VS2005. The build script is using components from VS2003 instead of VS2005 because the VS2003 paths (Path, LIB, LIBPATH and INCLUDE) were first declared before the VS2005 paths.
A simple SET command to override the environment variables with the "correct ones" fixed the build!
Thanks!
Related
I am a student who has gotten a part time job embedded system programming. I am given a program the company uses, and asked to understand it. This is a working program. Therefore, the project can be built and flashed on ESP32 by the developers with no problem. So, the code and CMake files should have no issues. However, I cannot build the program either with VSCode extension nor with idf.py. In fact, I cannot build esp-idf examples from the official website, either.
Note: I am new to StackOverflow as well as to ESP32, so sorry if I made any mistakes here. If this post is problematic in any way, please inform me.
The error message from the terminal is shown here
I was initially using VSCode on Windows 10 (Windows is not activated). At first, ESP extension was completely failing to start the building process because it could not locate the tools. I was getting "could not be located" errors for all the tools. Below is a list of what I did in this setting:
I had v5.0.0 for esp-idf downloaded from Espressif server. I deleted it and tried v4.3.3 and then I tried to download from Github server. I downloaded the requirements for idf.py scripting environment and completed the settings for it as described by the Espressif's documentation.
I manually set the environment variables for IDF_PATH and PATH for both the user and for the system.
After 2, the initial error was gone. Unfortunately, I had a new error which indicated that ".elf" file for the project output could not be found. I do not exactly recall the error but if it is integral to the problem's solution I can try to replicate this issue.
I tried to delete and reinstall VSCode. I tried running VSCode with admin authority.
I tried changing the IDF_TOOLS_PATH in the VSCode esp-idf extension configurations from ".espressif" to "esp\esp-idf".
At this point, I moved to try to build the project on Ubuntu 22.04.1 LTS:
In Ubuntu, I got the fatal error: esp_event.h: No such file or directory error.
It does not seem to be a common issue and I could not find much about it online.
I followed the Linux setup steps in the documentation. It said that only step 1 (Downloading the prerequisites) was necessary for the VSCode extension.
I decided to try the "master branch" from esp-idf configurations as well. After I downloaded the master branch, the error changed to the current version: 'fatal error: esp_wifi.h: No such file or directory'
I also tried the idf.py in Ubuntu but I got the same error.
Both in Ubuntu and in Windows, the Doctor Command returns nothing. It does not even open the terminal or any window. I am not sure what it should return but some online discussions were asking about its return so I wanted to note it here.
Edit: When I tried the examples on Ubuntu, they actually build just fine. Doctor Command also works with examples.
However, the main code has still issues. Initially, I assumed I made some mistakes with esp-idf configurations. But, perhaps that was not the case.
I had the same problem and ended up editing my project's CMakeLists.txt. When I added "esp_wifi" to the "REQUIRES" list, it worked for me:
idf_component_register(
SRCS "main.c"
INCLUDE_DIRS res
EMBED_FILES res/settings.html
REQUIRES esp_wifi
)
I'm trying to compile the SvnQuery project (https://github.com/kalyptorisk/svnquery.git) with the a version SharpSVN.dll which I created on my PC, but I keep seeing the error message CS0400: The type or namespace name 'SharpSvn' could not be found in the global namespace (are you missing an assembly reference?).
Using the SharpSVN.dll which comes with the SvnQuery source code, I do not see this error message, nor any other.
Both SharpSVN.dll files look the same when I open them in .NET Reflector, but there is one difference - the file which I created doesn't have version information. (To be exact: When you look at the file's properties in File Explorer, "File version" and "Product version" are empty.)
I followed these steps to create SharpSVN.dll:
Check out from https://ctf.open.collab.net/svn/repos/sharpsvn (tried trunk and the 1.1200x branch). Open VisualStudio command prompt (tried 2012, 2015 and 2017), cd to 'imports' folder, run 'nant build'. Result: no errors, but this doesn't create SharpSVN.dll (and I guess it shouldn't).
Now double-click SharpSvn.sln in the src folder. This opens VS2017. Compile Release|x86. Result: no errors, many warnings, SharpSVN.dll (with no version information) created in src\SharpSvn\bin\Win32\Release.
Any ideas about this issue?
Thanks...
I found the solution. My problem has nothing to do with the missing version number. In fact, I had compiled SharpSVN for a .NET version higher than that of the SvnQuery project. After increasing the .NET version number for SvnQuery and related projects, all compiled well. And SvnIndex.exe seems to run smoothly (test still ongoing).
For a very long time the following command worked as expected:
msbuild /property:Configuration=Release /property:TransformConfigFiles=true /property:DeployOnBuild=true /property:PublishProfile=FolderProfile /verbosity:normal /target:Rebuild /fileLogger /nologo /m Ticket.Corporativo.sln
By "expected" I mean, the project is built, then "packaged" into a "pkg" folder according to a publish profile called "FolderProfile" which is a simple file system deployment.
The last time it worked as expected was 2019-01-30. On the daily build of the 31st, the 'pkg' folder of "FolderProfile" was no longer created. Checking the build server, nothing we could track was changed... no updates, no nothing!
I've run out of ideas or items to check that could explain this failure... can anyone help?
PS:
-MSBuild version is 14.0
-Project being built
-Works on local machine as expected
I figured it out: Apparently, on my local machine, I added a reference to a package that was not available in our internal NUGET (only available on the public NUGET), which is the only source the builder machine has access... that caused an error, but was not reported as such, it failed silently... after copying the nuget pack to out server, it worked again perfectly
I have installed pycparser that parses C code.
Using pycparser I want to parse an open source project, namely PostgreSQL(version-11.0). I have build it using Visual Studio Express 2017 compiler suite. However, during compilation it cannot find some header files, namely windows.h and winsock2.h.
While looking at the directory structure of the build PostgreSQL, I find that it does not have these header files. How to fix this issue?
Also a strange error occurred as:
postgresql/src/include/c.h:363:2: error: #error must have a working
64-bit integer datatype
Note: I am using Windows 10 64-bit platform and postgresql-11.0
The steps are as follows:
I downloaded visual studio 2017, Windows-10 SDK, Active Perl as described in the steps to build from source in PostgreSQL.
After this I open the developer command prompt of Visual Studio and navigate to the folder postgresql-11.0/src/tools/msvc
Use command "build" to build postgresql. The build process was successful, but still windows.h and winsock2.h was not found in directory structure of PostgreSQL.
I don't know pycparser, but your problem probably has two aspects to it:
You didn't give pycparser the correct list of include directories. The header files you mention are not part of PostgreSQL.
Maybe you can get the list from the environment of the Visual Studio prompt. I don't have a Windows here to verify that.
The error message means that neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 are defined.
Now pg_config.h.win32, which is copied to pg_config.h during the MSVC install process, has the following:
#if (_MSC_VER > 1200)
#define HAVE_LONG_LONG_INT_64 1
#endif
Since you are not using MSVC, you probable don't have _MSC_VER set, which causes the error.
You could define _MSC_VER and see if you get to build then.
Essentially you are in a tight spot here, because pycparser is not a supported build procedure, so you'll have to dig into the source and fix things as you go. Without an understanding of the PostgreSQL source and the build process, you probably won't get far.
I am trying to figure out how to package an unchanged fork of VS Code.
My first steps were to follow the electron application distubution documentation, which has not been successful. I also found this post, where another user had the same question. However, the vscode-win32 gulp task seems to have been replaced by x64 and ia32 versions, and when I try running these tasks they generate an out-vscode folder as opposed to a full electron project.
This led me to believe that I can use this new out folder (as well as node modules, packages.json, etc.) with the electron release being used by VS Code to mimic the resources/app folder from the installed version of VS Code in Program Files, however when I try running electron.exe using this method I get:
The factory method of "vs/code/electron-main/main" has thrown an exception TypeError: Path must be a string. Received undefined
In short, I have been struggling with this for a couple of days, and I am out of ideas. If anyone has packaged the project and can offer a suggestion for how to do so, I would really appreciate it.
SOLVED
The issue seemed to be due to being branched off of master as opposed to release. I'd assume there are changes in main that aren't accounted for in the gulp task.
For anyone confused by my post, the expected behavior for a successful build is for a folder named VSCode-win32-x64 to be generated in the directory where your vscode clone is located.