KiCad / kicad-winbuilder

Windows builder for the KiCad project based on the MSYS2 MinGW system [moved to https://gitlab.com/kicad]
51 stars 24 forks source link

make_x86_64 fails #12

Closed ghost closed 6 years ago

ghost commented 9 years ago

I am on Windows 8.1 64-bit. I cloned KiCad-Winbuilder, then I ran make_x86_64.bat from an Administrator privileged command window. I noticed a number of error messages scroll by. The process ultimately quits with the following message:

-- HOME_DIR -- KICAD_PACKAGE_SOURCE_DIR /MINGW-packages/mingw-w64-kicad-git/ -- MSYS2 user name is: $USERNAME= -- Running cd /MINGW-packages/mingw-w64-kicad-git && export CARCH=x86_64 && makepkg-mingw -s --noconfirm 2>&1: line 0: cd: /MINGW-packages/mingw-w64-kicad-git: No such file or directory

It appears that the make file is just getting to building Kicad. The directory /MINGW-packages/mingw-w64-kicad-git does exist. However I obtain an error if I attempt to execute the export command from the command window.

Is there anything that I can try or look for?

ghost commented 8 years ago

Before I posted above I had tried the errant command: "cd /MINGW-packages/mingw-w64-kicad-git" in the DOS window that the build had been running in, and of course it works, since the directory had been created. I just thought to open a bash shell and try the same command, and of course it doesn't work, since the disk letter is a necessary part of the file path in bash, as in "cd /C/MINGW-packages/mingw-w64-kicad-git". The problem occurs at line 337 of the script:

execute_msys2_bash( "cd ${HOME_DIR}/MINGW-packages/mingw-w64-kicad-git && ${EXPORT_CARCH} makepkg-mingw -s --noconfirm" "${LOG_DIR}/makepkg" )

It would seem that ${HOME_DIR} hasn't been correctly defined.

nickoe commented 8 years ago

Yes, that is strange. I have seen another person report that the HOME_DIR variable was not set, but I can not reproduce it myself, so I have a hard time debugging it. Please spend some more time understanding how the cmake script works, and propose a better way to get that directory if you find one. :)

ghost commented 8 years ago

I'm terribly unfamiliar with cmake scripts so I may need a little help here.

I added a few message commands to the script, so my line numbers may be a bit off. On or about line 314 we have:

file( GLOB HOME_DIR "${CMAKE_SOURCE_DIR}/${MSYS2}/home/*" )

I obtained:

-- CMAKE_SOURCE_DIR C:/temp/KiCad-Winbuilder -- MSYS2 msys64 -- HOME_DIR -- KICAD_PACKAGE_SOURCE_DIR /MINGW-packages/mingw-w64-kicad-git/ -- MSYS2 user name is: $USERNAME=

I did a "cd C:\temp\KiCad-Winbuilder\msys64\home", and I found that that directory was empty. So I added a file to that directory, "FOO.TMP". Running the script again:

-- CMAKE_SOURCE_DIR C:/temp/KiCad-Winbuilder -- MSYS2 msys64 -- HOME_DIR C:/temp/KiCad-Winbuilder/msys64/home/FOO.TMP -- KICAD_PACKAGE_SOURCE_DIR C:/temp/KiCad-Winbuilder/msys64/home/FOO.TMP/MINGW-packages/mingw-w64-kicad-git/ -- MSYS2 user name is: $USERNAME=FOO.TMP

That was the wrong thing to do, because the script fails a couple of lines earlier than before. However, it looks like HOME_DIR is failing to be defined, because the "file GLOB" command (above) must be failing silently when there is nothing in the target directory.

From script, I can't see how the home directory is created and filled in. Also, I don't understand why the Msys user name (whatever that is) is derived from HOME_DIR. So I need some help here.

For further information, the Msys package was installed on this PC some time in the past, but it looks like it was removed. There are numerous other possibly interfering programs installed. Based on Wayne Stambach's advice, I reduced the path environment variable to:

PATH=C:\WINDOWS\system32;C:\Program Files (x86)\CMake\bin

but that made no difference to the outcome of the script. I'm running cmake version 3.4.0.

ghost commented 8 years ago

Nick, I reread your comment, the part about "propose a better way to get that directory if you find one". OK, so maybe understanding the script is not so important.

I don't know if there are any side effects, but it appears that the USERNAME variable serves no purpose in the script (other than to add to my confusion). So I changed the "file GLOB" command on or about line 314 to:

set( HOME_DIR "${CMAKE_SOURCE_DIR}/${MSYS2}/home" )

Now the script is happily filling up the disk. I'll report back if anything else goes awry.

ghost commented 8 years ago

More troubles... After the cmake script reported:

==> Finished making: mingw-w64-x86_64-kicad-git r6326.08d9b36-1 (Sat, Nov 21, 2015 00:14:26)

There is an error message about attempting to run ~/copydlls.sh:

-- Running ~/copydlls.sh --arch=x86_64 --pkgpath=$HOME/MINGW-packages/mingw-w6 4-kicad-git --nsispath=$HOME/nsis --makensis=C:/temp/KiCad-Winbuilder/.support /nsis-3.0b1/Bin/makensis.exe 2>&1: /c/Users/Embed2/copydlls.sh: No such file or directory

There is no copydlls.sh in the user home directory, but after the script ends there are copies in "C:\temp\KiCad-Winbuilder" and "C:\temp\KiCad-Winbuilder\msys64\home": The following command appears on or about line 341 of the script:

file( COPY "${CMAKE_SOURCE_DIR}/copydlls.sh" DESTINATION "${HOME_DIR}/" )

copydlls.sh is invoked in two places. On or about line 350 there is:

execute_msys2_bash( "$HOME/copydlls.sh \
                     --arch=i686 \
                     --pkgpath=$HOME/MINGW-packages/mingw-w64-kicad-git \
                     --nsispath=$HOME/nsis \
                     --makensis=${NSIS_MAKE_COMMAND}"
                     "${LOG_DIR}/copydlls_mingw32" )

On or about line 364 there is:

execute_msys2_bash( "~/copydlls.sh \
                     --arch=x86_64 \
                     --pkgpath=\$HOME/MINGW-packages/mingw-w64-kicad-git \
                     --nsispath=$HOME/nsis \
                     --makensis=${NSIS_MAKE_COMMAND}"
                     "${LOG_DIR}/copydlls_mingw64" )

The use of $HOME here instead of ${HOME_DIR} is problematic. So I changed $HOME and "~" to ${HOME_DIR} in each case.

Running the script again, I finally obtained an installer, however it was saved in the user home directory. That may be appropriate on Linux, but on a production Windows PC, it just isn't right. I would never think to mingle production code with my user trash. So I added the following to each of the above two commands:

         --outdir=${CMAKE_SOURCE_DIR}/out"

That's better.

bevanweiss commented 8 years ago

By any chance does your Windows username have a space in it? I had a similar issue, and it seemed to be related to non-quoted strings being passed to a command line, which causes issues if there is a space inside them. I've created a patch and generated a pull request, so it should get resolved shortly.

ghost commented 8 years ago

Sorry for the delay in responding. No, my user name on the build system is a single word. While working through the issues, I didn't see anything that could be called unusual about the build computer setup that would have interfered with the build. The script seems to make assumptions about the build environment that cannot be guaranteed, such as the existence of directories and files used by the script, before the script has even been run. It might be instructive to run the build in a sandbox with an empty environment and empty directory structure.

nickoe commented 8 years ago

Which dirs and files? Den 06/01/2016 16.06 skrev "Khalinda" notifications@github.com:

Sorry for the delay in responding. No, my user name on the build system is a single word. While working through the issues, I didn't see anything that could be called unusual about the build computer setup that would have interfered with the build. The script seems to make assumptions about the build environment that cannot be guaranteed, such as the existence of directories and files used by the script, before the script has even been run. It might be instructive to run the build in a sandbox with an empty environment and empty directory structure.

— Reply to this email directly or view it on GitHub https://github.com/nickoe/KiCad-Winbuilder/issues/12#issuecomment-169347613 .

ghost commented 8 years ago

Well, maybe just one file and one directory. See my comments above:

"it looks like HOME_DIR is failing to be defined, because the "file GLOB" command (above) must be failing silently when there is nothing in the target directory."

That doesn't seem like sensible behavior to me. Maybe it's a bug in the latest version of cmake.

While I was able to work my way through some of the simple cmake issues, there are still some things about it that I don't understand. If you'd like, I can issue a pull request and you can look at my actual changes in situ. On the whole, I didn't change much.

bevanweiss commented 8 years ago

Is the username that you're using really FOO.TMP? It wouldn't surprise me if the '.' was causing a problem. You should try initialising the msys environment, and then changing your username (and home dir) to be something without the '.' and re-running. You can do this by editing the /etc/passwd file if it exists. If it doesn't then you can make it with /usr/bin/mkpasswd > /etc/passwd then you can edit it. You should save it, and then restart msys. If you have stuff in your existing home directory then you would need to manually move them to the new home directory

ghost commented 8 years ago

There is no period in my username. It is "Mike2". FOO.TMP is actually the name of an empty file that I created in an "aborted" attempt to get past the one of the problems. If you look just above where I first mention FOO.TMP, you'll see that HOME_DIR was totally blank before I created the file.

bevanweiss commented 8 years ago

You are using the MSYS2 package that the WinBuilder configures? No manual changes to the files / environment?

Perhaps if you could have a look in the /etc/passwd file to make sure that there is an appropriate username for you. I suspect it's something about MSYS2 with your particular configuration.

ghost commented 8 years ago

I don't see any way that the winbuilder could be accessing any other copy of msys2. The only other copies of msys2 on that computer are minimal "private" copies installed by octave and git for their own use. "msys2" does not appear in either the environment or the registry. The only copy of mingw is the one installed by winbuilder. The only changes that I made to any files are detailed above. As I mentioned above, at one point I attempted to build with a minimal path, but that made no difference.

I'm not sure where I would find "/etc/passwd". The only passwd file on the entire system is one created or installed by the winbuilder. It is a shell script. I don't claim to understand the connection between msys2 and Cygwin, so perhaps I'm confused, but Cygwin dropped support for an actual passwd file some time ago. There is some Cygwin DLL that accesses the Windows account/security info instead. Cygwin64 is installed on that machine, but that should be irrelevant. As far as Windows is concerned, yes the account exists, it has a password and it has Administrator privilege.

nickoe commented 8 years ago

As far as I understand there is no such thing as a connection between cygwin and MSYS2. They are two projects with sort of similar goals, give you an unix-like environment on windows. IIRC MSYS2 is sort of a fork of MSYS using pacman as the package manager. Then there is the addition on MSYS2 that also supports mingw-w64 toolchains which can build for 32 and 64 bit windows.

Anyway, there are some pull requests that might fix the issues you are having, but I have not yet tested them.

ghost commented 8 years ago

The msys2 description at Source Forge says "MSYS2 is an independent rewrite of MSYS, based on modern Cygwin (POSIX compatibility layer) and MinGW-w64 with the aim of better interoperability with native Windows software." That might jibe with neither msys2 nor Cygwin having an etc/passwd.

As far as pull requests, I've fixed the problems that I found. The build works just fine with the changes that I made. However, the problems that I ran into don't seem to have an explanation yet.

ghost commented 8 years ago

While tracking down another problem I ran across the following lengthy exchange that points out some of the problems with the use of "~" in Kicad scripts, especially since "~" is not natively supported by Windows.

https://answers.launchpad.net/kicad/+question/252378

I point this out, because I used tilde above to solve some issues. It seems that cmake has no problem with tilde.

xarx00 commented 8 years ago

I'm lost in what problem you are solving right now. But I'm in impression that your problems are the same as described here: https://github.com/nickoe/KiCad-Winbuilder/issues/11. I posted a patch there that should solve the issues with the home dir, let me know if it works.

Unfortunately, in the last build, there is another issue that prevents correct build of KiCad, https://github.com/nickoe/KiCad-Winbuilder/issues/26. This one must be currently resolved by a manual intervention.

nickoe commented 6 years ago

No activity from OP.