search

gnieboer / GNURadio_Windows_Build_Scripts

A series of Powershell scripts to automatically download, build from source, and install GNURadio and -all- it's dependencies as 64-bit native binaries then package as an msi using Visual Studio 2015
GNU General Public License v3.0
89 stars 32 forks source link

Powershell error woes #38

Closed StakFallT closed 5 years ago

StakFallT commented 5 years ago

Not sure where to begin, I guess I'll put this out there and if more information is needed I'll be asked ;) Here is the relevant (I think anyhow) information:

Success.

Success.

So far so good...

Again, so far so good...

[ctrl]+[esc] cmd (right-clicked suggestion and clicked run as administrator) cd\ git clone http://www.github.com/gnieboer/GNURadio_Windows_Build_Scripts cd GNURadio_Windows_Build_Scripts powershell Set-ExecutionPolicy Unrestricted

Up to this point, everything's good...

Here's where things start to go awry...

./~RUNME_FIRST.ps1 The script starts by asking me the base directory, I accept the default, then immediately after it starts asking me for a BindingVariable. Looking into it, it appears the line (approximately) 308, has issues with the usage of the Import-LocalizedData cmdlet. Looking it up, I find the script seems to be missing -BindingVariable (https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/import-localizeddata?view=powershell-6)

However, not staying down, I decide to attempt to modify the script and make the line that says: $Config = Import-LocalizedData -BaseDirectory $mypath -FileName ConfigInfo.psd1

to:

Import-LocalizedData -BindingVariable "Config" -BaseDirectory $mypath -FileName ConfigInfo.psd1

Wonderful. Powershell is no longer yelling at me. Except now it's saying it has a hangup on line (approximately) 411 about not being able to set the Value parameter because it's Null. Line 411 says: Set-Alias git (Get-Command "git.exe").Source

Considering I used git to checkout the source for the project in the first place, that error is... interesting. So I ran the Get-Command cmdlet portion manually, and it came back as an empty line... So then I ran it again only this time without the .Source part and it came back with stuff.

Knowing git DOES exist on the system, and seeing that I CAN call it from PowerShell's command line, I decided to rem that and the if check out completely. Only then it started complaining about tar. I then decided to rem out every pre-requisite check. Now PowerShell is complaining about cl not being recognized.

I decide to try upgrading PowerShell to 3.0 thinking maybe these scripts were created using PS3 and the instructions just don't denote that. So I download Windows6.1-KB2506143-x64.msu (Windows Management Framework 3.0) from Microsoft and install that. One reboot later, I then try the process of going into Powershell, setting the execution policy... yadda yadda and re-running ./~RUNME_FIRST.ps1. I still get the cl error.

I chalk this up to not being in the Developer Command Prompt (the Installation & Build instructions do not delineate this). So I go ahead and do just that (that is, run the developer command prompt and run it as admin just to make sure), execute PowerShell, and type cl and hit enter to ensure the Dev prompt's setup carried over into PowerShell. It does. So I rerun ./~RUNME_FIRST.ps1 again, and now it's saying Split-Path : Cannot bind to parameter 'Path' because it is null. line 436 which has a Get-Command usage with the .Source member again.

At this point, I'm thinking I should stop (probably should have long ago) and post this in hopes that maybe I'm doing something wrong or there's an easy fix.

gnieboer commented 5 years ago

Hmm, the git.exe part is intriguing but might be a clue. Perhaps git wasn't installed for all users? In which case the Admin account might not have git on the path? A different PATH environment might also explain the lack of cl.exe?

I normally start with a powershell prompt, not the developer command prompt, and don't normally run as admin (you shouldn't need to generally).

Note that while I said that VS 15+ is fine, there will likely be issues with 17 as the CMAKE build setup will create VS2015 projects. So your mileage may vary, though it might be a simple find/replace with a good text editor.

Please remember, these scripts aren't meant for the faint of heart, so if you just want GNURadio to run on windows, please just use the binaries :).

Geof

On Tue, May 7, 2019 at 7:46 PM StakFallT notifications@github.com wrote:

Not sure where to begin, I guess I'll put this out there and if more information is needed I'll be asked ;) Here is the relevant (I think anyhow) information:

-

Created a 250GB Windows 7 x64 VM.

Fully Windows OS updated.

Installed Sublime text editor (more about user-experience QoL than anything)

Installed Chrome (I feel vulnerable just browsing the web using IE to download Chrome)

Installed Visual Studio 2017 (instructions said 2015 Community or higher -- which is just as well because Microsoft can't seem to get their directory naming structure straight, some versions it's Visual Studio, some versions it's Microsoft Visual Studio, some versions it's in x86 Program Files, other times it's in just regular Program Files... don't even get me started on the Windows SDK lol)

Installed Git

Downloaded the zip-form (didn't want it screwing with any registry settings or path variables since I knew 3.3 was going to be my target version) binaries for CMake 3.14 (apparently they don't offer binaries for 3.3 anymore -- or maybe they never did?)

Downloaded the source for CMake 3.3

Set my env. path for system, temporarily, to CMake 3.14's bin directory so I could go into CMake 3.3's directory and run cmake ../ from the directory, that I created in CMake's 3.3 root, called Build.

Success.

  • Started Visual Studio 2017, open CMake 3.3's newly generated (thanks to CMake 3.14) project / solution file. Right clicked on ALL_BUILD and clicked build.

Success.

-

Closed Visual Studio 2017

Changed my path environment variable from having CMake 3.14's bin directory in it to CMake 3.3's build\debug\bin directory

So far so good...

  • Installed ActiveState Perl
  • Installed Wix toolset for VS 2017

Again, so far so good...

[ctrl]+[esc] cmd (right-clicked suggestion and clicked run as administrator) cd\ git clone http://www.github.com/gnieboer/GNURadio_Windows_Build_Scripts cd GNURadio_Windows_Build_Scripts powershell Set-ExecutionPolicy Unrestricted

Up to this point, everything's good...

Here's where things start to go awry...

./~RUNME_FIRST.ps1 The script starts by asking me the base directory, I accept the default, then immediately after it starts asking me for a BindingVariable. Looking into it, it appears the line (approximately) 308, has issues with the usage of the Import-LocalizedData cmdlet. Looking it up, I find the script seems to be missing -BindingVariable ( https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/import-localizeddata?view=powershell-6 )

However, not staying down, I decide to attempt to modify the script and make the line that says: $Config = Import-LocalizedData -BaseDirectory $mypath -FileName ConfigInfo.psd1

to:

Import-LocalizedData -BindingVariable "Config" -BaseDirectory $mypath -FileName ConfigInfo.psd1

Wonderful. Powershell is no longer yelling at me. Except now it's saying it has a hangup on line (approximately) 411 about not being able to set the Value parameter because it's Null. Line 411 says: Set-Alias git (Get-Command "git.exe").Source

Considering I used git to checkout the source for the project in the first place, that error is... interesting. So I ran the Get-Command cmdlet portion manually, and it came back as an empty line... So then I ran it again only this time without the .Source part and it came back with stuff.

Knowing git DOES exist on the system, and seeing that I CAN call it from PowerShell's command line, I decided to rem that and the if check out completely. Only then it started complaining about tar. I then decided to rem out every pre-requisite check. Now PowerShell is complaining about cl not being recognized.

I decide to try upgrading PowerShell to 3.0 thinking maybe these scripts were created using PS3 and the instructions just don't denote that. So I download Windows6.1-KB2506143-x64.msu (Windows Management Framework 3.0) from Microsoft and install that. One reboot later, I then try the process of going into Powershell, setting the execution policy... yadda yadda and re-running ./~RUNME_FIRST.ps1. I still get the cl error.

I chalk this up to not being in the Developer Command Prompt (the Installation & Build instructions do not delineate this). So I go ahead and do just that (that is, run the developer command prompt and run it as admin just to make sure), execute PowerShell, and type cl and hit enter to ensure the Dev prompt's setup carried over into PowerShell. It does. So I rerun ./~RUNME_FIRST.ps1 again, and now it's saying Split-Path : Cannot bind to parameter 'Path' because it is null. line 436 which has a Get-Command usage with the .Source member again.

At this point, I'm thinking I should stop (probably should have long ago) and post this in hopes that maybe I'm doing something wrong or there's an easy fix.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gnieboer/GNURadio_Windows_Build_Scripts/issues/38, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYSW2LQNRB7KTXJVLELXDLPUIIELANCNFSM4HLNIWOA .

StakFallT commented 5 years ago

Hmm, the git.exe part is intriguing but might be a clue. Perhaps git wasn't installed for all users? In which case the Admin account might not have git on the path? A different PATH environment might also explain the lack of cl.exe?

I'm going to try reinstalling git and making sure it's available to all users. I'll let ya know how that goes.

I normally start with a powershell prompt, not the developer command prompt, and don't normally run as admin (you shouldn't need to generally). Note that while I said that VS 15+ is fine, there will likely be issues with 17 as the CMAKE build setup will create VS2015 projects. So your mileage may vary, though it might be a simple find/replace with a good text editor.

Interesting. Ok, I'll also give that shot. Also I'm fine with the potential issues of CMAKE creating VS15 projects. VS17 should tell me it detects them being older solution/project files and wants to know if I want to upgrade them.

Please remember, these scripts aren't meant for the faint of heart, so if you just want GNURadio to run on windows, please just use the binaries :).

No, I understand that. I'm fine with that. So (and maybe this will help you help me) I got excited when I saw this project.

Back story, I'm in college (graduate in two days), and looking to go to grad school for a PhD in cybersecurity. While in college, I worked in the information security department as basically the research arm. I primarily wrote in assembly (ia-32 and ia-64) for Windows (though I did do a shellcode PoC for Linux). Every year we would hold a tabling event in one of the atriums along side the various clubs and interest groups. We had a cheap but cool looking RC car to draw attention to students and faculty as they walked by to get them to stop and talk to us (anyone whose ever held a booth at a convention knows this struggle). This would give us a chance to engage the community and discuss things like password hygiene, safe internet practices, and inform the public about latest trending threats that could actually affect users, etc..

I decided, I was going to turn the car into a "spy-hunter" (reference to the NES game -- yes I know it was started as an arcade game :P ) type of car with on-board video, etc. I began disassembling the remote for the car, grabbed the specifications of the chip and reverse-engineered the communications going from the transmitter to the car. It wasn't easy because there were three different versions of the datasheet I found on the chip and not one of them was has the correct pulses, but it had general information that I was able to apply but I still had to get things like symbol duration, etc. correct on my own. I did it. I was successful!

However all of this was in GNURadio Companion. While GRC outputs to Python, that's fine. The problem is, I want a nice user-friendly interface that I can extend and expand upon with features over time. I knew writing a GUI in C/C++ was a pain, but still way better off than in Python. However, I found, while working in GameMaker Studio (hoping to actually make a game on the side as a fun little hobby project rather than the tedious hardwork of firmware reversing and research projects I put on myself), I found a library on YoYo Games' marketplace that utilized another library called ImGUI. I started working with the library, I found on the YYG marketplace, and really liked how easy it was to create an interface and it was using OpenGL. I looked at the API for ImGUI itself and was rather impressed with it being pretty easy to use. I also liked that if I wanted to do anything 3D down the line, I could. My work on the RC car had stalled for quite a while at one point because I needed a solution to a GUI in Python since getting GNURadio in C++ seemed to be a real dumpster-fire.

At one point I had gotten GNURadio to compile on my own without these PowerShell scripts but it was super-frankenstein'ish. I had grabbed header files from all sorts of various forks and revisions spread across the net, various lib files, etc. but I managed it.

Even eventually getting code to work in C++ I knew I still needed something better than something like MFC; I wanted it to be platform independent, so I started looking at the Mono project and what it would take to write swig interfaces for the classes I needed. I got the first set working, but then there were more interfaces that I needed that was -waaay- too much work. It eventually dawned on me that I had an answer for a platform independant GUI... ImGUI..

Problem is, I can't find my setup anymore :/ And I can't seem to figure out what I did to cause the access violation to no longer occur. I've tried tracing through the assembly call stack, but the PDBs are giving me issues. I can't seem to get the PDB set up correctly (either they're not the correct ones for the libraries I'm using, or they're not in the right path, etc.) so my call stack has a bunch of ??? in it between calls to the Kernel and without debugging symbols, the calls and jmps are just raw addresses with no real context-indicating purpose.

The other problem is, there is literally, from what I've seen, not one example of using the GNURadio library in C++. That's USING, not writing a module in C++ to be then used in Python. So I had to figure out what the necessary call orders were and what I needed to do code-wise to set up my C++ project so I could use GNURadio. I started with the top-block.py file and looked at what was being called, and tried to find the equivalents in the API documentation and then in the C++ header files. The problem I'm running into, no matter what version of GNURadio library I'm using, or what .lib and DLL files I find on the net that I try, I can compile my C++ project and it uses the GNURadio library but it always crashes on this line:

RF_Device = osmosdr::sink::make("hackrf=0000000000000000909864c8373081cf");

Access violation...

Looking at https://osmocom.org/projects/gr-osmosdr/wiki/GrOsmoSDR and trying various arguments and values as parameters, I still always get an access violation. It is my hope compiling it all from scratch on my own hardware for my own configuration should help, but I'm not sure. And knowing I can't seem to find the correct combination of files necessary to get GNURadio to compile from scratch, I was excited when I saw this project.

I recently tried to get GNURadio to compile from scratch and by modifying the various ENABLEGR prefixed CMake variables in CmakeCache.txt I can get it to look like it should be created the project files, but the cmake script still winds up complaining that there were errors despite me not seeing any in its output. So that's when I started looking around the net and found this project :)

Sorry, I know that was pretty long, but hopefully a bit of the back-story will help you help me :) In any case, in the meantime until you are able to get back to me, I'll try your suggestion about looking at git's install with more scrutiny and report back my findings. Thanks!

StakFallT commented 5 years ago

I just ran cmd.exe as both admin and regular (not-elevated) and git runs on both of those.

gnieboer commented 5 years ago

OK great, the backstory is good to know, and completely understand. In that case these builds may be just what you need, because my original intent was similar, to get a single compiler to build every library natively to avoid wierd cygwin vs msys vs MSVC compilation issues. I will also point out a fairly unique binary build on the website which is a full debug build all the way down the stack to core python. It's ridiculously slow, but if you are trying to troubleshoot a problem that might be GNURadio, might be a driver, or might be a dependency, then that stack is the way to go since you are obviously familiar with C++ level debugging/stack tracing.

Overall, I would still start with downloading the dependency packs first and just try building GNURadio (and the drivers) on it's own (once we figure out this issue). The good news is that the GR base code is now pretty windows friendly, and generally will build without issue. So that might be a good start for the osmocom issue since you'll have all the pdb files for those libraries. The build problems now are pretty much dependency-driven, especially trying to keep up with version updates that then cause breaking changes in the build structure (because as you'll see in the code and have lived through, there are some awkward/frankensteiny workarounds to get some of the code bases to build in MSVC).

I actually need to go make a new build, possibly this weekend as there is a new 3.7 version out and there are some fixes I need to incorporate. I've mostly been working on a 3.8 build off and on (which mostly works) though I haven't pushed that code up to github yet. So keep an eye out for some pushes sometime this month.

Now, as for the git detection issue, if it's not the admin issue, then it feels like it must be a PowerShell issue. The Set-Alias git (Get-Command... line is a somewhat recent addition to the code, originally it checked for the existence of some static paths if memory serves, and so would fail if git was someplace unexpected, and so this method should be more robust. But that still doesn't explain the later issue with not finding cl.exe. I checked my current powershell version, and I am running v5.1, so quite a bit newer (my build machine is now a Win10 machine), but the Get-Command is available in 3.0 so I don't think that's the issue. I would open non-admin powershell prompt and check if Get-Command "git.exe" manually returns an answer, and if not, check the value of $env:PATH in the powershell window.

On Wed, May 8, 2019 at 5:03 PM StakFallT notifications@github.com wrote:

Hmm, the git.exe part is intriguing but might be a clue. Perhaps git wasn't installed for all users? In which case the Admin account might not have git on the path? A different PATH environment might also explain the lack of cl.exe?

I'm going to try reinstalling git and making sure it's available to all users. I'll let ya know how that goes.

I normally start with a powershell prompt, not the developer command prompt, and don't normally run as admin (you shouldn't need to generally). Note that while I said that VS 15+ is fine, there will likely be issues with 17 as the CMAKE build setup will create VS2015 projects. So your mileage may vary, though it might be a simple find/replace with a good text editor.

Interesting. Ok, I'll also give that shot. Also I'm fine with the potential issues of CMAKE creating VS15 projects. VS17 should tell me it detects them being older solution/project files and wants to know if I want to upgrade them.

Please remember, these scripts aren't meant for the faint of heart, so if you just want GNURadio to run on windows, please just use the binaries :).

No, I understand that. I'm fine with that. So (and maybe this will help you help me) I got excited when I saw this project. Back story, I'm in college (graduate in two days), and looking to go to grad school for a PhD in cybersecurity. While in college, I worked in the information security department as basically the research arm. I primarily wrote in assembly (ia-32 and ia-64) for Windows (though I did do a shellcode PoC for Linux). Every year we would hold a tabling event in one of the atriums along side the various clubs and interest groups. We had a cheap but cool looking RC car to draw attention to students and faculty as they walked by to get them to stop and talk to us (anyone whose ever held a booth at a convention knows this struggle). I decided, I was going to turn the car into a "spy-hunter" (reference to the NES game -- yes I know it was started as an arcade game :P ) type of car with on-board video, etc. I began disassembling the remote for the car, grabbed the specifications of the chip and reverse-engineered the communications going from the transmitter to the car. It wasn't easy because there were three different versions of the datasheet I found on the chip and not one of them was has the correct pulses, but it had general information that I was able to apply but I still had to get things like symbol duration, etc. correct on my own. I did it. I was successful! However all of this was in GNURadio Companion. While GRC outputs to Python, that's fine. The problem is, I want a nice user-friendly interface that I can extend and expand upon with features over time. At one point I had gotten GNURadio to compile on my own without these PowerShell scripts but it was super-frankenstein'ish. I had grabbed header files from all sorts of various forks and revisions spread across the net, various lib files, etc. but I managed it. Problem is, I can't find my setup anymore :/ The other problem is, there is literally, from what I've seen, not one example of using the GNURadio library in C++. That's USING, not writing a module in C++ to be then used in Python. So I had to figure out what the necessary call orders were and what I needed to do code-wise to set up my C++ project so I could use GNURadio. I started with the top-block.py file and looked at what was being called, and tried to find the equivalents in the API documentation and then in the C++ header files. The problem I'm running into, no matter what version of GNURadio library I'm using, or what .lib and DLL files I find on the net that I try, I can compile my C++ project and it uses the GNURadio library but it always crashes on this line:

RF_Device = osmosdr::sink::make("hackrf=0000000000000000909864c8373081cf");

Access violation... Looking at https://osmocom.org/projects/gr-osmosdr/wiki/GrOsmoSDR and trying various arguments and values as parameters, I still always get an access violation. It is my hope compiling it all from scratch on my own hardware for my own configuration should help, but I'm not sure. And knowing I can't seem to find the correct combination of files necessary to get GNURadio to compile from scratch, I was excited when I saw this project.

I recently tried to get GNURadio to compile from scratch and by modifying the various ENABLEGR prefixed CMake variables in CmakeCache.txt I can get it to look like it should be created the project files, but the cmake script still winds up complaining that there were errors despite me not seeing any in its output. So that's when I started looking around the net and found this project :)

Sorry, I know that was pretty long, but hopefully a bit of the back-story will help you help me :) In any case, in the meantime until you are able to get back to me, I'll try your suggestion about looking at git's install with more scrutiny and report back my findings. Thanks!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gnieboer/GNURadio_Windows_Build_Scripts/issues/38#issuecomment-490650110, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYSW2NPZSA7ON62UEITSWDPUM52JANCNFSM4HLNIWOA .

StakFallT commented 5 years ago

Here's a back-and-forth of commands and their output that I think may be helpful

PS C:\Users\a> $PSVersionTable.PSVersion Major Minor Build Revision

3 0 -1 -1

PS C:\Users\a> $env:PATH %SystemRoot%\system32\WindowsPowerShell\v1.0\;C:\Perl64\site\bin;C:\Perl64\bin;C:\Windows\system32;C:\Windows;C:\Window s\System32\Wbem;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Git\cmd ;C:\Program Files\doxygen\bin;C:\cmake-3.3.0\build\bin\Debug;C:\Windows\System32\WindowsPowerShell\v1.0\ PS C:\Users\a> Get-Command "git.exe"

CommandType Name ModuleName

Application git.exe

PS C:\Users\a> Get-Command "cl.exe" Get-Command : The term 'cl.exe' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1

  • Get-Command "cl.exe"
  • 
+ CategoryInfo          : ObjectNotFound: (cl.exe:String) [Get-Command], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException,Microsoft.PowerShell.Commands.GetCommandCommand

PS C:\Users\a>

Just to double check, I went and looked at the path entry that specifies the v1.0 directory for PowerShell (both the system32 and SysWOW64 directories), the v1.0 directory is the only directory that is there, so I guess PS 3.0 doesn't add any. I also checked Program Files and Program Files (x86) and Common Files under both of those for something named PowerShell of some kind, and didn't see anything there. So I'm thinking the v1.0 part of the path is correct, oddly enough. (wtg Microsoft! lol). The PowerShell engine is a major version of 3 as per the initial command I entered.

Now what IS interesting is git.exe comes back fine with Get-Command, but cl.exe doesn't. I don't believe it's a path issue because both git.exe and cl.exe have an issue being found by the script. At first, I started thinking you might be right about it being a path issue and maybe you have cl.exe bin path in your path environment variable. However, I then looked at what developer console spawns and the shortcut calls this:

%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\VsDevCmd.bat"

When I look at what is inside of VsDevCmd.bat, I'd be -very- surprised if it was just a simple path entry needing to be added as it does stuff with setting up environment variables delineating what VS version it is, etc. This

@REM .NET Framework :core_dotnet if EXIST "%VS150COMNTOOLS%VsDevCmd\core\dotnet.bat" call :call_script_helper core\dotnet.bat

@REM msbuild :core_msbuild if EXIST "%VS150COMNTOOLS%VsDevCmd\core\msbuild.bat" call :call_script_helper core\msbuild.bat

@REM Windows SDK :core_winsdk if EXIST "%VS150COMNTOOLS%VsDevCmd\core\winsdk.bat" call :call_script_helper core\winsdk.bat

exit /B 0

is also a small sample, of that file. So it does a -ton- of things.

You had mentioned you typically start with PowerShell and not the developer console. Do you mean you don't run it (or even the .bat file) at all? If that's the case, I'm a little surprised that it works for you given all the stuff that batch file does. If you do run it (after you run PowerShell), I guess I'm kind've back to square one. I did get the pre-requisites to build. I'm wondering if they changed the syntax or default behavior or something of PS5 from 3.

EDIT: Formatting

gnieboer commented 5 years ago

So yes, I just start by running a basic powershell script. For me, cl.exe is on the normal PATH, and so opening a basic PS window and entering "cl" runs the compiler. Obviously looking at your PATH, that's not there. So that should be an easy fix.

After cl.exe is found, two lines later it runs the "vcvarsall.bat" file, which will set all the rest of those environment variables for you for that particular VS install, so essentially it's running the developer prompt prep stuff inside the scripts, and saving the original variables a bit later (to include the default compiler settings like LIB and LINK). So how all that other stuff gets set.

But it's all predicated on finding cl.exe on the path to begin with, and then working upwards to the location of that batch file. Feel free to replace that with a the actual location of vsvarsall.bat manually, and then it should be fine.

fingers crossed,

Geof

On Thu, May 9, 2019 at 5:15 PM StakFallT notifications@github.com wrote:

Here's a back-and-forth of commands and their output that I think may be helpful

`PS C:\Users\a> $PSVersionTable.PSVersion

Major Minor Build Revision

3 0 -1 -1

PS C:\Users\a> $env:PATH

%SystemRoot%\system32\WindowsPowerShell\v1.0;C:\Perl64\site\bin;C:\Perl64\bin;C:\Windows\system32;C:\Windows;C:\Window s\System32\Wbem;C:\Program Files\dotnet;C:\Program Files\Microsoft SQL Server\130\Tools\Binn;C:\Program Files\Git\cmd ;C:\Program Files\doxygen\bin;C:\cmake-3.3.0\build\bin\Debug;C:\Windows\System32\WindowsPowerShell\v1.0 PS C:\Users\a> Get-Command "git.exe"

CommandType Name ModuleName

Application git.exe

PS C:\Users\a> Get-Command "cl.exe" Get-Command : The term 'cl.exe' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1

  • Get-Command "cl.exe"
    • CategoryInfo : ObjectNotFound: (cl.exe:String) [Get-Command], CommandNotFoundException
    • FullyQualifiedErrorId : CommandNotFoundException,Microsoft.PowerShell.Commands.GetCommandCommand

PS C:\Users\a>`

Just to double check, I went and looked at the path entry that specifies the v1.0 directory for PowerShell (both the system32 and SysWOW64 directories), the v1.0 directory is the only directory that is there, so I guess PS 3.0 doesn't add any. I also checked Program Files and Program Files (x86) and Common Files under both of those for something named PowerShell of some kind, and didn't see anything there. So I'm thinking the v1.0 part of the path is correct, oddly enough. (wtg Microsoft! lol). The PowerShell engine is a major version of 3 as per the initial command I entered.

Now what IS interesting is git.exe comes back fine with Get-Command, but cl.exe doesn't. I don't believe it's a path issue because both git.exe and cl.exe have an issue being found by the script. At first, I started thinking you might be right about it being a path issue and maybe you have cl.exe bin path in your path environment variable. However, I then looked at what developer console spawns and the shortcut calls this:

%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\VsDevCmd.bat"

When I look at what is inside of VsDevCmd.bat, I'd be -very- surprised if it was just a simple path entry needing to be added as it does stuff with setting up environment variables delineating what VS version it is, etc. This

@rem https://github.com/rem .NET Framework :core_dotnet if EXIST "%VS150COMNTOOLS%VsDevCmd\core\dotnet.bat" call :call_script_helper core\dotnet.bat

@rem https://github.com/rem msbuild :core_msbuild if EXIST "%VS150COMNTOOLS%VsDevCmd\core\msbuild.bat" call :call_script_helper core\msbuild.bat

@rem https://github.com/rem Windows SDK :core_winsdk if EXIST "%VS150COMNTOOLS%VsDevCmd\core\winsdk.bat" call :call_script_helper core\winsdk.bat

exit /B 0

is also a small sample, of that file. So it does a -ton- of things.

You had mentioned you typically start with PowerShell and not the developer console. Do you mean you don't run it (or even the .bat file) at all? If that's the case, I'm a little surprised that it works for you given all the stuff that batch file does. If you do run it (after you run PowerShell), I guess I'm kind've back to square one. I did get the pre-requisites to build. I'm wondering if they changed the syntax or default behavior or something of PS5 from 3.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gnieboer/GNURadio_Windows_Build_Scripts/issues/38#issuecomment-491069107, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYSW2LJUESJ3G6HVHDIEFLPUSH5XANCNFSM4HLNIWOA .

StakFallT commented 5 years ago

Sorry for long delay in replying. In an effort to not hold up my project, I decided to try building against the debug binaries you provided (and they worked perfectly) and then I started tacking on the GUI. However, I still feel it would be great if I could get this to compile. I just added to my path variable, what I -think- (I say think because while cl.exe runs, the path to it is super deep) is the correct directory for cl.exe and re-ran PowerShell, here's the output from that:

PS C:\GNURadio_Windows_Build_Scripts> ~RUNME_FIRST.ps1 Please choose an absolute root directory for this build. <c:\gr-build>: Performing initial setup Setting up directories and checking dependencies... Split-Path : Cannot bind argument to parameter 'Path' because it is null. At C:\GNURadio_Windows_Build_Scripts\Setup.ps1:436 char:38

  • $VCdir = (Get-Command cl).Source | Split-Path -Parent | Split-Path -Parent | S ...
  • CategoryInfo : InvalidData: (:) [Split-Path], ParameterBindingValidationException
  • FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.SplitPathCo mmand

PS C:\GNURadio_Windows_Build_Scripts> cl Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27030.1 for x64 Copyright (C) Microsoft Corporation. All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ] PS C:\GNURadio_Windows_Build_Scripts> Get-Command cl.exe

CommandType Name ModuleName

Application cl.exe

PS C:\GNURadio_Windows_Build_Scripts> Write-Host (Get-Command cl.exe).Source

PS C:\GNURadio_Windows_Build_Scripts>

The entry I tacked onto the end of my PATH environment variable was: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\Hostx64\x64

gnieboer commented 5 years ago

So I am releasing v1.6 today, and for your use desire, the latest improvement is release of an AWS AMI that will provide the identical build environment that I used. There still may be a hiccup or two (usually transient internet issues) but should be a vastly improved experience. Plus there are a tons of fixes (many of which to were due to upgrading various packages and the changes those drove), so even if you still would like to use your own machine, it should be improved.