I'd like to use the ShellExecAsUser plugin with NSIS 3.08.
I have placed the plugin .dll Unicode version into the "Plugins\x86-unicode" and the ANSI version into the "Plugins\x86-ansi" directory.
When I do
!insertmacro ShellExecAsUser::ShellExecAsUser 'open' '$INSTDIR\bin\program.exe' '' '' ''
... then makensis produces the following error:
!insertmacro: macro named "ShellExecAsUser::ShellExecAsUser" not
found!
What do I need to do to make the plugin work?
Plug-ins don't use !insertmacro.
Just call it directly:
ShellExecAsUser::ShellExecAsUser "" cmd.exe "/k echo Hello" SW_SHOWDEFAULT
Related
I want to build https://github.com/wallix/redemption - and for the first time ever, I see bjam as a tool. This project has a tools/bjam/user-config.jam file.
The problem is, I'm trying to build this with a "custom" (that is, not the system version of) g++, which I have here:
$ which arm-linux-gnueabihf-g++-10
/home/pi/opt/gcc-10.1.0/bin/arm-linux-gnueabihf-g++-10
$ arm-linux-gnueabihf-g++-10 --version | head -n1
arm-linux-gnueabihf-g++-10 (pi-raspberry) 10.1.0
$ /home/pi/opt/gcc-10.1.0/bin/arm-linux-gnueabihf-g++-10 --v
ersion | head -n1
arm-linux-gnueabihf-g++-10 (pi-raspberry) 10.1.0
I guess, this qualifies at least as the compiler existing, right?
Anyways - I tried first, without knowing any better:
$ bjam --version
Boost.Build 2015.07-git
$ bjam toolset=arm-linux-gnueabihf-gcc-10 linkflags=-static-libstdc++ exe libs
arm.jam: No such file or directory
/usr/share/boost-build/src/build/toolset.jam:43: in toolset.using
ERROR: rule "arm.init" unknown in module "toolset".
/usr/share/boost-build/src/build-system.jam:461: in process-explicit-toolset-requests
/usr/share/boost-build/src/build-system.jam:527: in load
/usr/share/boost-build/src/kernel/modules.jam:295: in import
/usr/share/boost-build/src/kernel/bootstrap.jam:139: in boost-build
/usr/share/boost-build/boost-build.jam:8: in module scope
Then I found Building boost with different gcc version which mentions:
I cross built Boost for an ARM toolchain using something like this:
echo "using gcc : arm-unknown-linux-gnueabi : /usr/local/arm/bin/g++ ; " >> tools/build/v2/user-config.jam
Ok, so by that logic, I try:
echo "using gcc : arm-unknown-linux-gnueabi : /home/pi/opt/gcc-10.1.0/bin/arm-linux-gnueabihf-g++-10 ; " >> tools/bjam/user-config.jam
... and then:
$ bjam toolset=gcc-arm-unknown-linux-gnueabi linkflags=-static-libstdc++ exe libs
/usr/share/boost-build/src/tools/gcc.jam:123: in gcc.init from module gcc
error: toolset gcc initialization:
error: version 'arm-unknown-linux-gnueabi' requested but 'g++-arm-unknown-linux-gnueabi' not found and version '6.3.0' of default 'g++' does not match
error: initialized from
/usr/share/boost-build/src/build/toolset.jam:43: in toolset.using from module toolset
/usr/share/boost-build/src/build-system.jam:461: in process-explicit-toolset-requests from module build-system
/usr/share/boost-build/src/build-system.jam:527: in load from module build-system
/usr/share/boost-build/src/kernel/modules.jam:295: in import from module modules
/usr/share/boost-build/src/kernel/bootstrap.jam:139: in boost-build from module
/usr/share/boost-build/boost-build.jam:8: in module scope from module
Well, I agree that "version '6.3.0' of default 'g++' does not match" -> but how on earth is "'g++-arm-unknown-linux-gnueabi' not found"? What is that absolute path /home/pi/opt/gcc-10.1.0/bin/arm-linux-gnueabihf-g++-10 doing in that entry in user-config.jam otherwise?
So - can I get a more verbose printout of what actually bjam does in finding my compiler? Or even better, how can I format my "custom gcc" entry in user-config.jam, so I can get bjam to compile whatever it has to, and I can happily forget that bjam exists?
EDIT: even the official documentation for successor to bjam states:
When using gcc, you first need to specify your cross compiler in user-config.jam (see the section called “Configuration”), for example:
using gcc : arm : arm-none-linux-gnueabi-g++ ;
After that, if the host and target os are the same, for example Linux, you can just request that this compiler version to be used:
b2 toolset=gcc-arm
Isn't that exactly what I'm doing? Why doesn't it work then?
Well, I found a bit of documentation in /usr/share/boost-build/src/tools/gcc.jam:
# Initializes the gcc toolset for the given version. If necessary, command may
# be used to specify where the compiler is located. The parameter 'options' is a
# space-delimited list of options, each one specified as
# <option-name>option-value. Valid option names are: cxxflags, linkflags and
# linker-type. Accepted linker-type values are aix, darwin, gnu, hpux, osf or
# sun and the default value will be selected based on the current OS.
# Example:
# using gcc : 3.4 : : <cxxflags>foo <linkflags>bar <linker-type>sun ;
Ok, so here I have a string, delimited with colon, the seconf field says "3.4", the third field is empty - so WHERE does the "command may be used to specify where the compiler is located" go - in second or third field?
Well, I managed to get it running, quite hacky - I added these statements to /usr/share/boost-build/src/tools/gcc.jam:
...
rule init ( version ? : command * : options * )
{
#1): use user-provided command
local tool-command = ;
ECHO notice: 1) user-provided command '$(command)' version '$(version)' options '$(options)' ;
if $(version) = "arm"
{
command = arm-linux-gnueabihf-g++-10 ;
}
if $(command)
{
tool-command = [ common.get-invocation-command-nodefault gcc : g++ :
$(command) ] ;
ECHO notice: tool-command 1) user-provided '$(command)' '$(tool-command)' ;
...
The printouts were like:
notice: 1) user-provided command version 'arm' options
notice: tool-command 1) user-provided 'arm-linux-gnueabihf-g++-10' 'arm-linux-gnueabihf-g++-10'
...
... both 'command' and 'options' there are empty - as if the line I added to user-config.jam does not get parsed beyond the two first fields.
So, since the second field ("arm") does get parsed, I simply added a conditional on it, and forced the use of the command - and now that passes.
Well, I wish bjam just worked, and I did not have to go through this ...
Nsis 3 supports new commands like Unicode true. I want a script that works with makensis2 and makensis3. Is this possible? I use linux.
I tried to write a script. But the compiler doens't accept this
Update:
!if "${NSIS_PACKEDVERSION}" > 0x02ffffff ; NSIS 3+
Unicode true
ManifestSupportedOS all
!else
!warning "NSIS v2, compiling ANSI installer!"
!endif
I use this but get still the error message warning 7070: Invalid number: "${NSIS_PACKEDVERSION}".
${If} is a run-time command but you need to use preprocessor instructions and all of those start with !.
!if "${NSIS_PACKEDVERSION}" > 0x02ffffff ; NSIS 3+
Unicode true
!else
!warning "NSIS v2, compiling ANSI installer!"
!endif
This is the official way but might not work with unofficial releases if VER_PACKED was not passed to SCons when building MakeNSIS.
Here is something that relies on the improved number parser in NSIS v3 instead:
!if 0n1 > 0 ; >= 3.0b0 (Documented in chapter 5.1)
Unicode true
!else
!warning "NSIS v2, compiling ANSI installer!"
!endif
My build.hxml file looks like this:
-main Main
-cp src
-js bin/index.js
I use js.Browser in Main class. When I try to build it with F8, FlashDevelop gives me "You cannot access the js package while targeting cross". And I actually see that it tries to run:
Running process: bla-bla-bla -target "js"
...
cmd: cmd /c haxe build.hxml
haxe -cp src -main Main
So it removes -js parameter from hxml and then fails the build. How to fix it?
In the project properties, choose "Custom Build" as compilation target.
The reason is that the hxml target uses a custom build command (Build tab) and when the Application compilation target is selected, FD will try to compile it a second time with an incorrect configuration. This is legitimately a bug in FD - raise an issue on Github?
I have used Export Makefile option from VC++ 6.0 project.
Getting this error
make -f simu.mak
simu.mak:4: *** missing separator. Stop.
These are few lines of my makefile
# Microsoft Developer Studio Generated NMAKE File, Based on simu.dsp
!IF "$(CFG)" == ""
CFG=simu - Win32 PC Debug
!MESSAGE No configuration specified. Defaulting to simu - Win32 PC Debug.
!ENDIF
!IF "$(CFG)" != "simu - Win32 PC Debug" && "$(CFG)" != "simu - Win32 PC Release"
!MESSAGE Invalid configuration "$(CFG)" specified.
!MESSAGE You can specify a configuration when running NMAKE
!MESSAGE by defining the macro CFG on the command line. For example:
!MESSAGE
!MESSAGE NMAKE /f "simu.mak" CFG="simu - Win32 PC Debug"
!MESSAGE
That is not a makefile. It's an nmake file (as it says, right at the top of the file :)). You cannot use GNU make with that makefile, you must use Windows nmake.
I am using a mix of Java and native JNI C++ code for an android project, using NDK r8b, in Eclipse in OSX. I want to be able to use the regular C++ classes (map, string) in std namespace.
In the Android.mk file the following were added:
APP_STL := stlport_shared
Here I also tried static library. Refer to http://docs.huihoo.com/android/ndk/r5/CPLUSPLUS-SUPPORT.html
STLPORT_FORCE_REBUILD := true
Also tried removing the forced build.
In the C/C++ path and variables:
${NDKROOT}/sources/cxx-stl/stlport/stlport
"map" and "string" headers were included in the .cpp file. I am able to use std::string and std::map. The assistant picks up on them. When searching for the definition (F3 in eclipse) the header file is shown, i.e. resolved. Also, the outline shows the "string" and "map" header files and when double clicking them it also brings the headers to the forefront.
However, the build doesn't pick them up. I get the following:
> ndk-build
> Gdbserver : [arm-linux-androideabi-4.6] libs/armeabi/gdbserver
> Gdbsetup : libs/armeabi/gdb.setup
> Gdbserver : [arm-linux-androideabi-4.6] libs/armeabi-v7a/gdbserver
> Gdbsetup : libs/armeabi-v7a/gdb.setup
> Compile++ arm : ImageTargets <= ImageTargets.cpp
> xxx/Project/Code/MyImageTarget/jni/ImageTargets.cpp:20:18: fatal error: string: No such file > or directory
> compilation terminated.
> make: *** [xxx/Project/Code/MyImageTarget/obj/local/armeabi/objs-> debug/ImageTargets/ImageTargets.o] Error 1
Has anyone any idea what else is there to try.
Use V=1 parameter on ndk-build command line. This will echo all executed commands, including compilation and link, with all their parameters that NDK build assigns.
In your case, the answer can be found without detailed build log:
In the Android.mk file the following were added:
APP_STL := stlport_shared
This is your mistake. The document you cited explains that this setting should go into Application.mk. This file is usually considered optional. Yes it is. Instead of creating this file, you can specify APP_STL on the command line:
ndk-build V=1 APP_STL=stlport_static
I don't know why and how Eclipse resolves #include <string> or map.