Can someone explain and/or provide reference for understanding how NSIS registers work. For example, $0, $1. I see examples of using them.
Like {If} $0 == ''
Do something
I don't understand how you can put values into $0 or how values are there dynamically?
Please help, thank you.
From the NSIS Sourceforge docs, located here, Registers are already-defined variables available for use:
These variables can be used just like user variables, but are usually used in shared functions or macros. You don't have to declare these variables so you won't get any name conflicts when using them in shared code. When using these variables in shared code it's recommended that you use the stack to save and restore their original values. These variables can also be used for communication with plug-ins because they can be read and written by the plug-in DLLs.
Variables are handled like strings in NSIS, so to put a value into one of these Register variables, such as $0, you would do a command like:
StrCpy $0 WhatValueYouWantToBeInZero
Related
I have a custom environment set up for my tests:
test_env = env.Clone()
test_env.Append(LIBS=['boost_unit_test_framework'])
But for one of my tests, I want to link against an additional library:
test_env.Program('foo_tests',
source='foo/tests.cpp',
LIBS=['extralib'],
LIBPATH=['.'])
Sadly this overrides the LIBS from the environment, when I'd like it to just add to it. Is there a better (i.e. more canonical) way to do this than LIBS=test_env['LIBS'] + ['extralib']?
Specifying a new value for an environment variable in a Builder call (like Program) is always interpreted as an "override". So there is no way around compiling the full replacement value, as you did in your example above.
The other option would be to Clone the environment "test_env" again, and then use Append to add the "extralib" to LIBS...
It's possible to do it like this:
test_env.Program('foo_tests',
source='foo/tests.cpp',
LIBS=['$LIBS', 'extralib'],
LIBPATH=['$LIBPATH', '.'])
SCons is clever enough to properly expand the variable into a list there.
Is there anyway to include file by mention it with variable? I mean
StrCpy $1 "bla.nsh"
!include $1
?
or maybe getting value of variable that called by another variable such as:
StrCpy $1 "EN"
StrCpy $2 ${LANG_${1}_WELCOME_MESSAGE}
?
Thanks.
Variables can only be used at runtime (running on the end-users machine), you need to use defines:
!define foo "bar"
!include "${foo}.nsh"
Edit:
You should be using the LangString instruction if you want to add custom translated strings, you can access a langstring at runtime with $(mystringid).
Actually, Anders right. Think about that, when the compiler compiling your code, it need to know which files it need to include with your EXE file.
About the variable, you can use only with defines. again, because when you are compiling, the compiler will compile all the needed (in use) variables / defines, and you can't tell him use one that never been declared.. its little different from server side languages because here you are compiling and pack your code into EXE file which is assembled in your computer.
I am very new to mib2c, and I need to list all attributes which belong to one variable.
I work with mib2c tool from NET-SNMP and there are configuration templates for generating the code.
There are variables with many attributes, look like:
$var.defval
$var.type
I would like to see all these attributes, in order to use them in the generated code.
I know, for mib2c attributes there is man page, but there is not everything. (For example I know the attribute $var.needlength exists, and it is not mentioned in that man page).
I don't know how the $var is defined and fulfilled.
How can I list all attributes of $var?
I'm not sure how you can do this programmatically, given the constraints of the mib2c pseudo-Perl but I just looked in /usr/bin/mib2c (it's a script, not a compiled executable so you can easily examine the code) and found the following.
There are only four undocumented variables in the mib2c script:
lastchange
storagetype
needlength
enumrange
There are many more documented variables in the mib2c script:
uc
objectID
commaoid
oidlength
subid
module
parent
isscalar
iscolumn
children
perltype
type
decl
readable
settable
creatable
noaccess
accessible
rowstatus
hasdefval
defval
hashint
hint
ranges
enums
access
status
syntax
reference
description
That being said, I'm not sure what exactly you are hoping to find, so I'm not sure that this really answers your question.
I'm writing a Qt app that runs in Linux. I need to write a file to:
"$XDG_CONFIG_DIRS/whatever"/ "$HOME/whatever"
How do I resolve the environment variables ## Heading ##in my code?
Using nothing but plain library functions, you use getenv() to look up the value of environment variables:
const char *dirs = getenv("XDK_CONFIG_DIRS");
This will return NULL if the variable was not set in the environment, so make sure your code handles this case.
You'll have to do the "interpolation" of the variable values into the rest of the text yourself, in that case.
Not sure if Qt provides a wrapper or something more high-level that can do the interpolation for you, I haven't worked with Qt.
getenv, as already mentioned, if you really only target Linux. If you want it portable to Non-Unix platforms, you should use qgetenv() or QProcessEnvironment::systemEnvironment().value(QLatin1String("XDG_CONFIG_DIRS")). In general, it's good practice to use the portable Qt way.
I'm trying to profile our shared library, but whenever I have the environmental variable LD_PROFILE set, I get "PLTREL not found in object ". What gives? Is there some sort of linker flag I'm missing or what? There seems to be no information about this on the internets. The man page for sprof is about 10 words long.
According to an unanswered question on Google Groups, it looks like you aren't the very first person with this problem.
I think pltrel means plt-relative; in some ELF design notes,
There is a .plt section created in the code segment, which is an array of function stubs used to handle the run-time resolution of library calls.
And here's yet a little more:
The next section I want to mention is the .plt section. This contains the jump table that is used when we call functions in the shared library. By default the .plt entries are all initialized by the linker not to point to the correct target functions, but instead to point to the dynamic loader itself. Thus, the first time you call any given function, the dynamic loader looks up the function and fixes the target of the .plt so that the next time this .plt slot is used we call the correct function. After making this change, the dynamic loader calls the function itself.
Sounds to me like there's an issue with how the shared library was compiled or assembled. Hopefully a few more searches to elf PLT section gets you on the right track.
Found this that may be relevante for you:
Known issues with LD_AUDIT
➢ LD_AUDIT does not work with Shared Libraries with no code in them.
➢ Example ICU-4.0 “libicudata.so”
➢ Error: “no PLTREL found in object /usr/lib/libicudata.so.40”
➢ Recompile after patching libicudata by sed'ing -nostdlib etc away sed -i --
"s/-nodefaultlibs -nostdlib//" config/mh-linux
It seems the same applies for LD_PROFILE