I installed ghost and ghost-CLI on Windows 10. When I run ghost start I get the error below. how to fix this? It seems related to the command to check file and folder permissions. Note that I'm running ghost in the D: drive.
By the way, if I run ghost run it works.
D:\onlinehelp>ghost start
Process manager 'systemd' will not run on this system, defaulting to 'local'
√ Checking current folder permissions
√ Validating config
× Checking folder permissions
× Checking file permissions
√ Checking memory availability
One or more errors occurred.
1) Checking folder permissions
Message: Command failed: C:\WINDOWS\system32\cmd.exe /q /s /c "find ./ -type d ! -perm 775 ! -perm 755"
FIND: Parameter format not correct
Exit code: 2
2) Checking file permissions
Message: Command failed: C:\WINDOWS\system32\cmd.exe /q /s /c "find ./ -type f ! -path "./versions/*" ! -perm 664 ! -perm 644"
File not found - ./
File not found - -TYPE
File not found - F
File not found - !
File not found - -PATH
File not found - !
File not found - -PERM
File not found - 664
File not found - !
File not found - -PERM
File not found - 644
Exit code: 1
Debug Information:
OS: Microsoft Windows, v10.0.16299
Node Version: v8.9.1
Ghost-CLI Version: 1.7.2
Environment: production
Command: 'ghost start'
Additional log info available in: C:\Users\pablo\.ghost\logs\ghost-cli-debug-2018-05-01T16_58_30_857Z.log
Try running ghost doctor to check your system for known issues.
Please refer to https://docs.ghost.org/v1/docs/troubleshooting#section-cli-errors for troubleshooting.
D:\onlinehelp>
This isn't an ideal solution but it worked for me.
Ghost uses linux's find command to check permissions, this command does not exist on windows (or at least the windows find command does not accept the same arguments.
I was pretty sure my permissions were fine, so I decided to bypass the check.
To do so, locate where ghost-cli is installed globally, in my case it was
C:\Users\your-name-here\AppData\Roaming\npm\node_modules\ghost-cli
In there, you want to find lib\commands\doctor\checks\check-permissions.js
you will notice a line that starts with
return execa.shell(
This is the line we want to avoid, to do so, we can return a result before it is run, in my case I added the line return Promise.resolve();
e.g.
return Promise.resolve();
return execa.shell(checkTypes[type].command, {maxBuffer: Infinity}).then((result) => {
...
Related
I upgraded an existing (and working!) Vaadin application that was using v18.0.2 to v21.0.4. With that new version the server side application starts up as usual, it initializes OK and the first requests triggers the frontend compilation (which also seems to work OK, at least the log shows no abnormalities or errors), but the UI just hangs and fails to load (there is a thin blue progress bar at the top of the page which quickly reaches about 50% of the width, then it gets slower and slower and then starves at about 90% of the screen width).
I don't have the slightest clue in which direction I should check or analyze this. Any suggestion or hint what could be wrong here would be highly appreciated!
If I should attach any config or log details to help analyzing this let me know!
Later addendum:
I attach my vaadin_dance.cmd here:
#echo off
:package_entries
set fn=package.json
echo Step 1: Going to remove unsupported Vaadin v19+ entries from %fn%:
pause
rem let user see what we do:
#echo on
type %fn% | findstr /V /C:"#vaadin/application-theme-plugin" > %fn%_1
type %fn%_1 | findstr /V /C:"#vaadin/stats-plugin" > %fn%_2
type %fn%_2 | findstr /V /C:"#vaadin/theme-live-reload-plugin" > %fn%_3
type %fn%_3 | findstr /V /C:"#vaadin/theme-loader" > %fn%_4
rem remove an already existing backup - just in case (if there were one the cp below won't work)
rm %fn%~
rem rename back to original and keep a backup:
cp -b -f %fn%_4 %fn%
rem delete the temp. files":
rm %fn%_?
#echo off
echo unsupported Vaadin v19+ entries removed from %fn%
:local_stuff
echo Step 2: Going to remove project local stuff:
pause
rem let user see what we do:
#echo on
rmdir /S /Q .\target
rmdir /S /Q .\node_modules
rmdir /S /Q .\frontend\generated
rm package.json
rm package-lock.json
rm pnpm-lock.yaml
rm pnpmfile.js
rm tsconfig.json
rm types.d.ts
rm webpack.config.js
rm webpack.generated.js
#echo off
echo project local vaadin-generated stuff removed.
:global_stuff
echo Step 3: Going to remove global stuff: removing pnpm stuff
pause
rem let user see what we do:
#echo on
rm -r -f %USERPROFILE%\.pnpm-debug.log
rm -r -f %USERPROFILE%\.pnpm-state.json
rmdir /S /Q %USERPROFILE%\.vaadin
rmdir /S /Q %USERPROFILE%\.pnpm-store
rem just in case - I encountered them here, too:
rmdir /S /Q D:\.pnpm-store
rmdir /S /Q U:\.pnpm-store
#echo off
echo global vaadin-installed stuff removed.
rem clear (and preload) default repository:
:repo_stuff
echo Step 4: Going to empty m2repository!
pause
rem let user see what we do:
#echo on
rem strange enough I again and again got "access denied" on certain .jars ||-( So we first take ownership...
takeown /R /F %USERPROFILE%\.m2\m2repository
rem ... before removing the stuff:
rm -r -f %USERPROFILE%\.m2\m2repository\*
#echo off
echo m2repository cleaned.
echo.
pause
The process with the above .cmd file is such, that I run first step 1, then I stop it and try to rebuildv(in a different cmd window). If that does not work, I restart it from begin and run steps 1 & 2, then I stop and try to rebuild, etc. At most after steps 1, 2, 3 & 4 I was (at least so far) always able to rebuild and execute my application. That's at least when build with or reverting to v18.0.3. With v21.x I haven't been successful so far. :-(
Second addendum with the console output:
The application starts up OK (i.e. without any error message( up to the point where I see "Tomcat has been started on port: ..."
At that point I direct my browser to that port which triggers the dispatching of the DispatcherServlet. That page never loads and the browser times out, but there is NO error message or anything giving a hint re. the type or cause of the problem on the console:
...
2021-12-17 19:36:03,459 INFO [main] org.springframework.boot.web.embedded.tomcat.TomcatWebServer: Tomcat started on port(s): 8085 (http) with context path ''
2021-12-17 19:36:23,678 INFO [http-nio-8085-exec-1] org.apache.juli.logging.DirectJDKLog: Initializing Spring DispatcherServlet 'dispatcherServlet'
2021-12-17 19:36:23,682 INFO [http-nio-8085-exec-1] org.springframework.web.servlet.FrameworkServlet: Initializing Servlet 'dispatcherServlet'
2021-12-17 19:36:23,689 INFO [http-nio-8085-exec-1] org.springframework.web.servlet.FrameworkServlet: Completed initialization in 2 ms
2021-12-17 19:36:26,103 WARN [http-nio-8085-exec-1] org.apache.juli.logging.DirectJDKLog: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [2,172] milliseconds.
2021-12-17 19:36:26,103 WARN [http-nio-8085-exec-3] org.apache.juli.logging.DirectJDKLog: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [1,457] milliseconds.
2021-12-17 19:36:26,179 INFO [http-nio-8085-exec-4] com.vaadin.flow.spring.SpringInstantiator: The number of beans implementing 'I18NProvider' is 0. Cannot use Spring beans for I18N, falling back to the default behavior
<Console output stops here and browser times out>
Unfortunately there seems no way to attach screenshots here, so I can't provide the output of the WebDeveloper's Network Tab's output here...
The Browser Inspector Console displays:
Fri Dec 17 2021 19:52:01 GMT+0100 (Central European Standard Time) Atmosphere: unload event vaadinPush-min.js:1:40213
Vaadin push loaded vaadinPush-min.js:1:44231
Failed to register/update a ServiceWorker for scope ‘http://localhost:8085/’: Bad Content-Type of ‘text/html’ received for script ‘sw-runtime-resources-precache.js’. Must be a JavaScript MIME type.
Uncaught (in promise) TypeError: ServiceWorker script at http://localhost:8085/sw.js for scope http://localhost:8085/ threw an exception during script evaluation.
Path '/login' is not properly resolved due to an error. Resolution had failed on route: '(.*)' vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58:17000
Uncaught (in promise) TypeError: class heritage e is not an object or null
to http://localhost:8085/VAADIN/build/vaadin-3-1a44b245d20aa3c33130.cache.js:1
266 http://localhost:8085/VAADIN/build/vaadin-3-1a44b245d20aa3c33130.cache.js:765
r http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:1
promise callback*imports http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
flowInit http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
async*get action/< http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
Z http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
__resolveRoute http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
promise callback*__resolveRoute http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
resolveRoute http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
a http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
a http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
promise callback*a http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
resolve http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
promise callback*resolve http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
render http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
__onNavigationEvent http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
setRoutes http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
<anonymous> http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
r http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:1
<anonymous> http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:1
<anonymous> http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:1
vaadin-3-1a44b245d20aa3c33130.cache.js:1:153
How is a non-Vaadin intern supposed to decode that stuff and analyse what's going wrong here?
I got the issue replicated and the problem is that in development mode I got a 400 (Bad Request) in the console from Flow.ts with the faulty response Error 400 Invalid location: Location parameter missing from bootstrap request to server.
The fix was to delete the ./frontend/generated folder after which the application worked as it should when running mvn clean jetty:run. But the vaadin:clean-frontend goal should remove the generated folder in frontend which at least for me was the problem.
Check the inspector and look if there is any exceptions in the console.
I just upgraded to v22.0.1. With that new version my application now loads again! Beats me what was broken in versions 19.0.x - 21.0.4 that caused my application's UI to not load.
But there are still one issue:
The initial page is not the application's main-page but some odd self-additionalManifestEntries-page (see my append
Vaadin v22: Odd page displayed each time after login to application). I always need to reload the main page to enter my actual application.
I am a web developer with no experience in iOS development. Now I'm using Cordova to build iOS app. Because I have no knowledge about iOS or Xcode, it is very hard for me. I always get error like the following output when I built in Xcode or built in command line.
Error info in Xcode build:
Run custome shell script 'Copy www directory'
PhaseScriptExecution Copy\ www\ directory /Users/jyjin/Library/Developer/Xcode/DerivedData/myios-auhioanpfinvvvcrnvoaioslreyr/Build/Intermediates.noindex/myios.build/Debug-iphonesimulator/myios.build/Script-304B58A110DAC018002A0835.sh (in target: myios)
cd /Users/jyjin/workspace/gitProject/Cordova/FirstProject/platforms/ios
/bin/sh -c /Users/jyjin/Library/Developer/Xcode/DerivedData/myios-auhioanpfinvvvcrnvoaioslreyr/Build/Intermediates.noindex/myios.build/Debug-iphonesimulator/myios.build/Script-304B58A110DAC018002A0835.sh
/Users/jyjin/Library/Developer/Xcode/DerivedData/myios-auhioanpfinvvvcrnvoaioslreyr/Build/Intermediates.noindex/myios.build/Debug-iphonesimulator/myios.build/Script-304B58A110DAC018002A0835.sh: line 2: 27158 Segmentation fault: 11 node cordova/lib/copy-www-build-step.js
Command PhaseScriptExecution failed with a nonzero exit code
Error info in command line build:
** BUILD FAILED **
The following build commands failed:
PhaseScriptExecution Copy\ www\ directory /Users/jyjin/Library/Developer/Xcode/DerivedData/myios-auhioanpfinvvvcrnvoaioslreyr/Build/Intermediates.noindex/myios.build/Debug-iphonesimulator/myios.build/Script-304B58A110DAC018002A0835.sh
(1 failure)
xcodebuild: Command failed with exit code 65
I have read a lot of solutions on websites, and finally I found that there were some script in build phase:
NODEJS_PATH=/usr/local/bin; NVM_NODE_PATH=~/.nvm/versions/node/`nvm version 2>/dev/null`/bin; N_NODE_PATH=`find /usr/local/n/versions/node/* -maxdepth 0 -type d 2>/dev/null | tail -1`/bin; XCODE_NODE_PATH=`xcode-select --print-path`/usr/share/xcs/Node/bin; PATH=$NODEJS_PATH:$NVM_NODE_PATH:$N_NODE_PATH:$XCODE_NODE_PATH:$PATH && node cordova/lib/copy-www-build-step.js
after checking out the error message several times, I tried to remove && node cordova/lib/copy-www-build-step.js in Build Phases, it builds successfully, but with no page effect expected in html (Cause no www resource copied I think).
and I tried to check out some env PATH value in copy-www-build-step.js,so I wrote some log code in copy-www-build-step.js, but have no idea how to print js logs in Xcode. Then I found cordova-plugin-console, but npm doc said it is duplicated, and contains the last version for Cordova, and mine is also the latest.
Oh, God!One week passed... I just want to build an iOS app. It’s so hard to play. The ghost knows what I experienced:Configuring certificates, profile, building a Cordova app from scratch, even spending $99 to buy an apple developer account...
Just want to play an iOS app by myself in my free time ... Hope someone can help me ~~
-- From a desperate Chinese boy !
just update cordova-ios to latest version:
npm i cordova-ios#latest
you can see this problem being solved in this PR: #600, they changed the script from javascript to the old shell version and fixed the problem.
Workaround without updating the library
Enter in xCode in the Build Phases tab and click on "Copy www directory" phase, so change the script to:
$SRCROOT/__PROJECT_NAME__/Scripts/copy-www-build-step.sh
"__PROJECT_NAME__ " is the name of xCode project.
After this download the copy-www-build-step.sh script and put it inside the "__PROJECT_NAME__/Scripts/" path.
References
https://github.com/apache/cordova-ios/issues/540
https://github.com/apache/cordova-ios/pull/600/files
https://github.com/apache/cordova-ios/pull/146/files
Oh! I have fixed it~
Firstly, check the script:
NODEJS_PATH=/usr/local/bin; NVM_NODE_PATH=~/.nvm/versions/node/`nvm version 2>/dev/null`/bin; N_NODE_PATH=`find /usr/local/n/versions/node/* -maxdepth 0 -type d 2>/dev/null | tail -1`/bin; XCODE_NODE_PATH=`xcode-select --print-path`/usr/share/xcs/Node/bin; PATH=$NODEJS_PATH:$NVM_NODE_PATH:$N_NODE_PATH:$XCODE_NODE_PATH:$PATH && node cordova/lib/copy-www-build-step.js
currently error is xcodebuild: Command failed with exit code 65. This is the first error, the && should be & when running in the mac.
And then, the error turn to be Command /bin/sh failed with exit code 127.And I found xcode error message: node: command not found.
So I run find /usr/local/n/versions/node/* -maxdepth 0 -type d 2>/dev/null | tail -1 in the command line. and get the node result path /usr/local/n/versions/node/11.12.0
run
node -v // v10.15.3
So I remove all script in build_phases, and give it node path for my real nvm node path, change build_phases like below:
/Users/jyjin/.nvm/versions/node/v10.15.3/bin/node cordova/lib/copy-www-build-step.js
Build success!
Summary! cordova auto build_phases script maybe not suit your environment, make sure build phase can get your node path!
I'm running into a problem attempting to upload the "blink" app onto the motes. I can't seem to run the command make telosb reinstall bsl,/dev/ttUSB0 or make telosb reinstall while in the apps/Blink directory, which is preventing me from moving on with my project. I've tried as a user, superuser, and as root. I've outlined below the responses from variable commands. [Running Ubuntu 16.04, TinyOS 2.1.2, ncc version 1.4.2, nescc version 1.3.6]
(A)With root and the make telosb command I get back:
mkdir -p build/telosb
compiling BlinkAppC to a telosb binary
ncc -o build/telosb/main.exe -Os -fnesc-separator=__ -Wall -Wshadow -Wnesc-all -target=telosb -fnesc-cfile=build/telosb/app.c -board= -DDEFINED_TOS_AM_GROUP=0x22 -DIDENT_APPNAME=\"BlinkAppC\" -DIDENT_USERNAME=\"root\" -DIDENT_HOSTNAME=\"liam-Latitude-E\" -DIDENT_USERHASH=0x9236fe46L -DIDENT_TIMESTAMP=0x59384a62L -DIDENT_UIDHASH=0xdc08609fL BlinkAppC.nc -lm
compiled BlinkAppC to build/telosb/main.exe
2538 bytes in ROM
56 bytes in RAM
msp430-objcopy --output-target=ihex build/telosb/main.exe build/telosb/main.ihex
writing TOS image
(B)With regular user and the make telosb command I get back:
mkdir -p build/telosb
/bin/sh: 1: cannot create build/telosb/ident_flags.txt: Permission denied
/home/liam/tinyos-main/support/make/ident_flags.extra:13: recipe for target 'ident_cache' failed
make: *** [ident_cache] Error 2
(C)With a super user and the sudo make telosb command I get back:
make: *** No rule to make target 'telosb'. Stop.
(D)With root and the make telosb reinstall command I get back:
cp build/telosb/main.ihex build/telosb/main.ihex.out
found mote on /dev/ttyUSB0 (using bsl,auto)
installing telosb binary using bsl
tos-bsl --telosb -c /dev/ttyUSB0 -r -e -I -p build/telosb/main.ihex.out
MSP430 Bootstrap Loader Version: 1.39-goodfet-8
Mass Erase...
Transmit default password ...
Invoking BSL...
Transmit default password ...
Current bootstrap loader version: 1.61 (Device ID: f16c)
Changing baudrate to 38400 ...
MSP430 Bootstrap Loader Version: 1.39-goodfet-8
Mass Erase...
Transmit default password ...
Invoking BSL...
Transmit default password ...
Current bootstrap loader version: 1.61 (Device ID: f16c)
Changing baudrate to 38400 ...
Traceback (most recent call last):
File "/usr/bin/tos-bsl", line 1918, in <module>
main(0);
File "/usr/bin/tos-bsl", line 1843, in main
speed=speed,
File "/usr/bin/tos-bsl", line 1218, in actionStartBSL
self.actionChangeBaudrate(speed) #change baudrate
File "/usr/bin/tos-bsl", line 1345, in actionChangeBaudrate
self.serialport.setBaudrate(baudrate)
AttributeError: 'Serial' object has no attribute 'setBaudrate'
/home/liam/tinyos-main/support/make/msp/bsl.extra:45: recipe for target 'program' failed
make: *** [program] Error 1
(E)Whereas with a regular user and make telosb reinstall I get back:
cp build/telosb/main.ihex build/telosb/main.ihex.out
cp: cannot create regular file 'build/telosb/main.ihex.out': Permission denied
/home/liam/tinyos-main/support/make/msp/msp.rules:92: recipe for target 'setid' failed
make: *** [setid] Error 1
I have been all over the internet and online forums and haven't found a fix yet. I researched around (D) and found that perhaps python 2 might have changed the name of 'setBaudRate' variable. I'm not sure how to change that either.
Thank you for your time and help!
edit: added ncc and nescc versions.
This stack overflow answer is applicable to TinyOS.
So it turns out that pyserial 3.0.1 is not compatible with the TinyOS app, Blink. I'm fairly certain that pyserial 3.0.1 came with the package for TinyOS. To fix this, use the command sudo pip install "pySerial>=2.0,<=2.99999". For me, it kicked back:
The directory '/home/liam/.cache/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
The directory '/home/liam/.cache/pip' or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
Collecting pySerial<=2.99999,>=2.0
Installing collected packages: pySerial
Found existing installation: pyserial 3.0.1
DEPRECATION: Uninstalling a distutils installed project (pySerial) has been deprecated and will be removed in a future version. This is due to the fact that uninstalling a distutils project will only partially uninstall the project.
Uninstalling pyserial-3.0.1:
Successfully uninstalled pyserial-3.0.1
Successfully installed pySerial-2.7
But the blink app still uploaded and worked fine.
This is basically the same issue as in mingw ld cannot find some library which is exist in the search path, MinGW linker can't find MPICH2 libraries - and I'm aware that there are heaps of posts on StackOverflow regarding the issue of static and dynamic linking with MinGW - but I couldn't find anything that explains how I can troubleshoot.
I am building a project with a huge linker command like (via g++) on MinGW, in a MSYS2 shell (git-bash.exe). The process fails with, among others:
/z/path/to/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lssl
I add -Wl,--verbose to the g++ linker call (to be passed to ld), and I can see for the -L/z/path/to/libs/openssl/lib/mingw -lssl:
...
attempt to open /z/path/to/libs/openssl/lib/mingw/libssl.a failed
...
/z/path/to/libs/openssl/lib/mingw/ssl.dll failed
attempt to open /z/path/to/libs/openssl/lib/mingw\libssl.a failed
...
But this is weird, because the file exists?
$ file /z/path/to/libs/openssl/lib/mingw/libssl.a
/z/path/to/libs/openssl/lib/mingw/libssl.a: current ar archive
(... and it was built with the same compiler on the same machine)?
Weirdly, once it attempts to open with forward slash .../libssl.a, once with backslash ...\libssl.a - but at least the first path checks out in a bash shell, as shown above?
It gets even worse if I try to specify -l:libssl.a -- or if I specify -L/z/path/to/libs/openssl/lib/mingw -Wl,-Bstatic -lssl -- instead; then all attempts to open are with a backslash:
...
attempt to open /z/path/to/scripts/other/build/openssl/build/mingw/lib\libssl.a failed
attempt to open /z/path/to/libs/openssl/lib/mingw\libssl.a failed
...
To top it all off, if I look it up manually through the command line using ld, it is found ?!:
$ ld -L/z/path/to/libs/openssl/lib/mingw -lssl --verbose
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.dll.a failed
attempt to open Z:/path/to/libs/openssl/lib/mingw/ssl.dll.a failed
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
Does anyone have an idea why this happens, and how can I get ld to finally find these libraries? Or rather - how can I troubleshoot, and understand why these libraries are not found, when they exist at the paths where ld tries to open them?
OK, found something more - not sure if this is a bug; but my problem is that I'm actually reading arguments from a file (otherwise I get g++: Argument list too long). So, to simulate that:
$ echo " -Wl,--verbose -L/z/path/to/libs/openssl/lib/mingw -lssl -lcrypto " > tmcd3
$ g++ #tcmd3 2>&1 | grep succeeded | grep ssl
# nothing
$ g++ `cat tcmd3` 2>&1 | grep succeeded | grep ssl
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
attempt to open Z:/path/to/libs/openssl/lib/mingw/libcrypto.a succeeded
... it turns out, if the very same arguments are fed on the command line, then static library lookup succeeds - but if the arguments are read from file through the # at-sign, then static library lookup fails?! Unfortunately, I cannot use on my actual project, since even with cat, I'd still get g++: Argument list too long ... So how can I fix this?
MSYS has special handling of directories as arguments when they are used in the shell. This translates e.g. /<drive_letter>/blabla to the proper Windows style paths. This is to accomodate Unix programs that don't handle Z: style directory root.
What you see here is that MSYS isn't performing this interpretation for string read from a file. When you think about it, it's very logical, but as you have experienced first-hand, also sometimes annoying.
Long story short: don't put Unix style paths in files with command arguments. Instead, pass them through e.g. cygpath -w, which works in MSYS2 (which should be the MSYS that Git for Windows 2+ comes with).
Ok, with some more experiments, I noticed that:
-L/z/path/to/libs/openssl/lib/mingw, the Unix path specification, tends to fail - while if we specify the same, except starting with a Windows drive letter, that is:
-LZ:/path/to/libs/openssl/lib/mingw, then things work - also from an arguments file with # at-sign:
$ echo " -Wl,--verbose -LZ:/path/to/libs/openssl/lib/mingw -lssl -lcrypto " > tmcd3
$ g++ #tcmd3 2>&1 | grep succeeded | grep ssl
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
attempt to open Z:/path/to/libs/openssl/lib/mingw/libcrypto.a succeeded
I guess, since the shell is MSYS2/git-bash.exe, entering full POSIX paths on the shell with /z/... is not a problem, because the shell will convert them - but in a file, there is nothing to convert them, so we must use Windows/MingW convention to specify them...
I keep running lb build, fixing problem after problem and then running it again, and now i'm getting this message:
dpkg: warning: 'start-stop-daemon' not found in PATH or not executable
dpkg: error: 1 expected program not found in PATH or not executable
Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin
E: Sub-process /usr/bin/dpkg returned an error code (2)
P: Begin unmounting filesystems...
P: Saving caches...
Reading package lists... Done
Building dependency tree... Done
I then went to check my path and i see
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
This clearly shows /usr/local/sbin, /usr/sbin, and /sbin.
Any suggestions?
**UPDATE 1**
Followed this guide
http://ubuntuforums.org/showthread.php?t=1449322
every command ran fine but still the same error message after running lb build again.
**UPDATE 2 -- Additional Info**
root#kali:~# ls -lA /sbin
(Other files)
-rwxr-xr-x 1 root root 28208 Aug 12 15:00 start-stop-daemon
First, you must check the feedback information from the first line (although it is just a warning).
Then, you must have understand that the warning is the key. All the mistakes are caused by this warning. You have to add start-stop-daemon to your pc.
According to the following:
cd /tmp
wget http://developer.axis.com/download/distribution/apps-sys-utils-start-stop-daemon-IR1_9_18-2.tar.gz
tar zxf apps-sys-utils-start-stop-daemon-IR1_9_18-2.tar.gz
cd apps/sys-utils/start-stop-daemon-IR1_9_18-2/
gcc start-stop-daemon.c -o start-stop-daemon
cp start-stop-daemon /usr/local/bin/start-stop-daemon
Now you can help yourself,and others
I have the same problem, according to https://debianforum.de/forum/viewtopic.php?f=34&t=155279 (in german) the only known solution is to run sudo lb clean before sudo lb build.