We have Intersystems Cache 2010.2.3.702.0.10761 installed on AIX. When I run an eXtreme - Globals API program I am seeing LCBJNI related errors.
Does the Cache 2010.2.3.702.0.10761 have lcbjni? If so, where can I find. Please help
2010.2 requires an extra step on Unix. You need to Set the environment variable LD_PRELOAD to the path of libjsig.so. Here is [documentation]http://docs.intersystems.com/cache20102/csp/docbook/DocBook.UI.Page.cls?KEY=BLXT_intro#BLXT_intro_config
find $JAVA_HOME -name libjsig.so -print
setenv LD_PRELOAD /my_jdk_path/jdk1.6.0_11/jre/lib/amd64/libjsig.so
you have to check for correct GLOBALS_HOME, PATH and CLASSPATH envirroment variables.
check it in documentation
Related
Changing the path of a Yocto environment is not a good idea, as I found out. This also explains why e.g. bitbake can be run regardless the current working directory. Absolute paths are stored in many places during the build process, even subdirectory structures are created into the tmp directory tree. I ended up in rebuilding from scratch - which takes a long time.
A documentation of how I tried to modify all paths:
find . -name *.conf -exec sed -i 's/media\/rob\/3210bcd4-49ef-473e-97a6-e4b7a2c1973e/home/g' {} +
This step replaces absolute paths, within many dynamic conf files (from xx/xx/linux to /home/linux - where linux was chosen for historical reasons. I could mount the partition also as /home/yocto or whatever name).
Next was deletion of subdirectory structures with the old path in the hope that the build process would recognize these deletions, and still rebuild quickly:
find . -name *3210bcd4-49ef-473e-97a6-e4b7a2c1973e* -exec fakeroot rm -r {} +
It was not recognized. Then I gave up.
From a user new to Yocto, familiar with former/classic crossbuild environments based on make menuconfig etc.
My question is:
Why are absolute paths generated & used throughout tmp instead of treating everything as relative?
Or, asked differently:
Why not use something like ${TOPDIR}/tmp throughout the build configuration, instead of hardcoding the absolute path to tmp?
I'm looking for a way to specify the output path of the generated .coverage file. I've checked coverage help and did some research but still no luck so far. The reason is that I would like it to be specified into our tmp directory.
You can create a .coveragerc and specify the path for .coverage using the data_file attribute under the [run] section.
This is the link to the current documentation.
You can use the [run] data_file setting (https://coverage.readthedocs.io/en/latest/config.html#run), or the COVERAGE_FILE environment variable (https://coverage.readthedocs.io/en/latest/cmd.html#data-file).
I'm working on an RPM package that deploys files to /opt and /etc.
In most of the cases it works perfectly, excepted that for a given environment, writing to /etc is not allowed ....
So I used Relocations in order to deploy the /etc files in some other location :
Relocations : /opt /etc
By specifying --relocate option I can deploy the /etc files into another location :
rpm -ivh --relocate /etc=/my/path/to/etc mypackage.rpm
Now the issue is that in the postinstall script, there are some hard coded references to /etc that don't get replaced when the package is deployed :
echo `hostname --fqdn` > /etc/myapp/host.conf
I hope that there is a way (macro, keyword, ... ) to use instead of hard coded paths in order to perform the substitutions during rpm execution.
If you have any information on this I'd really appreciate some help.
Thanks per advance
PS : Please note that this is NOT a duplicate of the previously asked (and answered) questions related to the root path re-locations as we're dealing with several relocation paths and the fact that we need to handle each of them separately during rpm scriptlets
Many thanks to Panu Matilainen from the RPM mailing list who answered the question. I'll re-produce his mail literally in order to share the knowledge :
I assume you mean (the above is how rpm -qi shows it though):
Prefixes: /opt /etc
The prefixes are passed to scriptlets via $RPM_INSTALL_PREFIX<n>
environment variables, <n> is the index of supported prefixes starting
from zero. So in the above,
/opt is $RPM_INSTALL_PREFIX0
/etc is $RPM_INSTALL_PREFIX1
So the scriptlet example becomes:
echo `hostname --fqdn` > $RPM_INSTALL_PREFIX1/myapp/host.conf
Works like a charm, thank you very much Panu !
I got the following error while starting JBoss from a command line prompt today:
'findstr' is not recognized as an internal or external command
Please google it, you can find a lot of answers. But do as below to fix it. Add the following value to Right Click My Compuer -> Advanced -> Environment Variables -> System Variables -> Select Path variable -> append the below value.
C:\WINDOWS\system32
It should work with that change.
As others pointed, issue is in wrong settings of PATH variable in Windows.
According to article this is most probably because some stupid installer wrongly modified PATH variable in Windows registry. Registry has 2 different string value types - REG_SZ and REG_EXPAND_SZ. Only the second one allows for expansion of %SystemRoot%.
So check your path by typing set path in command prompt. If you see unexpanded %SystemRoot% and other variables in Path, you are affected (PATH should show only plain directory names, not variables).
You need to edit Path variable in registry: HKEY_CURRENT_USER\Environment and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment. As it is not possible to change the type of key, save the path value somewhere, delete the key and re-create it with type REG_EXPAND_SZ. You need to logout for changes to take effect.
for me it works when I've coped findstr(from windows/system32) to wildfly/bin
Please go throught the simplest steps:-
go to C:\Windows\system32\ and copy findstr.exe file.
paste this file into the location C:\Program Files\Java\jdk1.6.0_24\bin
Run your jboss again you will get out of this.....
Check to see if you %SystemRoot% is evaluating (type set path into a command prompt, you should not see %SystemRoot%, but instead that actual path). If your path variable's (user, or systems) first entry begins with an %(an environment variable) this can cause an issue.
To resolve this, simply swap this first entry with anything else in your path that does not lead with an environment variable.
You can also hard code the directory by replacing 'findstr' with 'C:\Windows\system32\findstr'. This is useful when using systems with restricted user permissions.
I have try to work with play framework but stuck with to run activator.bat file but solution is the same just copy file from windows/system32/findsr and past it to under stuck folder then run the respective file again.
thanks to andrewsiand Suryaprakash
Please beware that current Windows systems use a Capital "S" for the System directory, so:
C:\WINDOWS\System32
%SystemRoot%\System32
Omitting the capital S will result in a neglect of the line in the %PATH%
In my case (not JBoss related) the following helped to fixed this error.
Instead of:
SET path="%path%;C:\some\additional\path"
I used:
SET "path=%path%;C:\some\additional\path"
For IBM ACE solution for
'findstr' is not recognized as an internal or external command,
Go to the path C:\Windows\System32
Find the findstr.exe, copy it and then find the path where you bin file of your application is found. eg C:\Program Files\IBM\ACE\11.0.0.12\server\bin then past it inside the bin file
cancel the console of ace and re-open it.
Then run ACE toolkit command on ace console.
Then press enter, now it can open.
Okay this is and isn't programming related I guess...
I've got a whole bunch of little useful console utilities scattered across a suite of projects that I wrote and I want to dump them all to a single directory to make using them simpler. The only issue is that I have them all compiled in both Debug and Release mode.
Given that I only want the release mode versions in my utilities directory, what switch would allow me to specify that I want all executables from my tree structure but only from within Release folders:
Example:
Projects\
Project1\
Bin\
Debug\
Project1.exe
Release\
Project1.exe
Project2\
etc etc...
To
Utilities\
Project1.exe
Project2.exe
Project3.exe
Project4.exe
...
etc etc...
I figured this would be a cinch with XCopy - but it doesn't seem to allow me to exclude the Debug directories - or rather - only include items in my Release directories.
Any ideas?
You can restrict it to only release executables with the following. However, I do not believe the other requirement of flattening is possible using xcopy alone. To do the restriction:
First create a file such as exclude.txt and put this inside:
\Debug\
Then use the following command:
xcopy /e /EXCLUDE:exclude.txt *.exe C:\target
You can, however, accomplish what you want using xxcopy (free for non-commercial use). Read technical bulletin #16 for an explanation of the flattening features.
If the claim in that technical bulletin is correct, then it confirms that flattening cannot be accomplished with xcopy alone.
The following command will do exactly what you want using xxcopy:
xxcopy /sgfo /X:*\Debug\* .\Projects\*.exe .\Utilities
I recommend reading the technical bulletin, however, as it gives more sophisticated options for the flattening. I chose one of the most basic above.
Sorry, I haven't tried it yet, but shouldn't you be using:
xcopy release*.exe d:\destination /s
I am currently on my Mac so, I cant really check to be for sure.
This might not help you with assembling them all in one place now, but going forward have you considered adding a post-build event to the projects in Visual Studio (I'm assuming you are using it based on the directory names)
xcopy /Y /I /E "$(TargetDir)\$(TargetFileName)" "c:\somedirectory\$(TargetFileName)"
Ok, this is probably not going to work for you since you seem to be on a windows machine.
Here goes anyway, for the logic.
# From the base directory
mkdir Utilities
find . -type f | grep -w Release > utils.txt
for f in $(<utils.txt); do cp $f Utilities/; done
You can combine the find and cp lines into one, I split them for readability.
To do this on a windows machine you'll need Cygwin or some such Unix Utilities handy.
Maybe there are tools in the Windows shell to do this...
This may help get you started:
C:\>for %i in (*) do dir "%~dpi\*.exe"
Used in the dir command as a modifier to i, ~dp uses the drive and path of everything found in (*). If I run the above in a folder that has several subfolders containing executables, I get a dir list of all of the executables in each folder.
You should be able to modify that to add '\bin\release\' following the ~dpi portion and change dir to xcopy. A little experimentation should make it pretty easy.
To use the for statement above in a batch file, change '%' to '%%' in both places.