I am a newbie to Creo toolkit. For trial purpose, I need to edit the location of the source and target folders in the default make-file available. A part of the make-file is given below for reference.
# File Name
MAKEFILENAME = make_install
# Machine Type
PRO_MACHINE_TYPE = x86e_win64
# Executable names
EXE = pt_inst_test.exe
EXE_DLL = pt_inst_test.dll
# Pro/Toolkit Source & Machine Loadpoint (EXTERNAL USE - DEFAULT)
PROTOOL_SRC = $(PROE_INSTALL_PATH)\protoolkit
PROTOOL_SYS = $(PROTOOL_SRC)/$(PRO_MACHINE_TYPE)
# Pro/Toolkit Source & Machine Loadpoint (PTC INTERNAL USE)
#PROTOOL_SRC = $(PTCSRC)/protoolkit
#PROTOOL_SYS = $(PTCSYS)
# Include File Paths
INCS = -I. -I$(PROTOOL_SRC)/protk_appls/includes -I$(PROTOOL_SRC)/includes
In the above given code, I need to replace the source (PROE_INSTALL _PATH) with the required folder location (For ex: C:\Users\sagarp\Desktop\trial) without editing the environment variable. Is it possible? If so, please help me with the basics of creating a make-file on my own.
I just started using Creo toolkit and saw this question.
It's an old question but I'd still post the answer.
You can update the
PROTOOL_SRC = $(PROE_INSTALL_PATH)\protoolkit
by giving relative path.
It could be current dir or whatever you prefer.
Example for current dir :
PROTOOL_SRC = .
PROTOOL_SYS = $(PROTOOL_SRC)/$(PRO_MACHINE_TYPE)
Related
I am new to scripting. I was trying to create a chocolatey package that would automatically do a custom(not typical) install. For example with MariaDB installations, I would like to specify which parts of the server to install and the username and password for the database.
I was trying to practice on Libreoffice where the package chooses Custom install and intalls only libre Writer. But the following script does the default installations what am I missing here? thanks.
chocolateinstall.ps1
e$ErrorActionPreference = 'Stop'; # stop on all errors
$toolsDir = "$(Split-Path -parent $MyInvocation.MyCommand.Definition)"
$fileLocation = ".\LibreOffice_7.2.7_Win_x64.msi"
$pp= Get-PackageParameters
if (!$pp['SetupType']){$pp['SetupType']='Custom'}
if (!$pp['InstallOption']){$pp['InstallOption']='LibreWriter'}
$packageArgs = #{
packageName = $env:ChocolateyPackageName
unzipLocation = $toolsDir
fileType = 'msi'
file = $fileLocation
softwareName = 'libre*'
checksum = '...'
checksumType = 'sha256'
silentArgs = "/qn /norestart /l*v `"$($env:TEMP)\$($packageName).$($env:chocolateyPackageVersion).MsiInstall.log`"" # ALLUSERS=1 DISABLEDESKTOPSHORTCUT=1 ADDDESKTOPICON=0 ADDSTARTMENU=0
validExitCodes= #(0, 3010, 1641)
}
Install-ChocolateyPackage #packageArgs
This is a pretty huge question, to one extent, and quite easy in another!
Short answer:
Your example above doesn't pass any of the package arguments you're crafting (e.g. $pp['InstallOption']) to the actual installer. They're being stored in the variable ($pp) and never used.
The values you want to use should be passed in to Install-ChocolateyPackage using the silentArgs parameter.
However, I don't think the arguments you have there are going to work, even if you pass them in (though I may be mistaken).
Longer answer:
MSIs don't just accept random arguments.
Accepted arguments vary hugely by installer, and by software, and there's no guarantee you can do what you want silently from the commandline.
You can use something like Orca to find out what arguments an MSI may support, or search for documentation (or other folk having done the work before), or create an MST file to apply.
You could also use the Chocolatey for Business Package Builder, which scans the file and tries to identify useful arguments you can pass - though this requires a paid Business license for Chocolatey.
I need to add some board-specific code to a Linux kernel which I am building.
(I know I should be using device-tree already, but the driver I'm inspired by doesn't and I'm already learning a dozen new things before breakfast. Adding device-tree will also add another set of changes to debug. Once I have my platform-driver/drivers working using a board file, I will convert them to device tree.)
I have a file called arch/arm/myboard/myboard.c.
Where do I find existing board files in make menuconfig? (Such as http://lxr.free-electrons.com/source/arch/arm/mach-imx/mach-mx31ads.c?v=4.4 ?)
How do I make my board appear here also.
Take a look at the Makefile in the same directory. For mach-mx31ads.c, it has,
# i.MX31 based machines
obj-$(CONFIG_MACH_MX31ADS) += mach-mx31ads.o
The Kconfig has a corresponding entry,
config MACH_MX31ADS
bool "Support MX31ADS platforms"
default y
select IMX_HAVE_PLATFORM_IMX_I2C
select IMX_HAVE_PLATFORM_IMX_SSI
select IMX_HAVE_PLATFORM_IMX_UART
select SOC_IMX31
help
Include support for MX31ADS platform. This includes specific
configurations for the board and its peripherals.
Adding these will give your board a Kconfig menu item and build the file. The only other missing piece is a machine type. You need to add this to arm/tools/mach-type which is processed by the kernel makefile, using the gen-mach-types script, to create a generated/mach-type.h. You use this in your board file to create a static machine description (put in a special section).
MACHINE_START(MX31ADS, "Freescale MX31ADS")
/* Maintainer: Freescale Semiconductor, Inc. */
.atag_offset = 0x100,
.map_io = mx31ads_map_io,
.init_early = imx31_init_early,
.init_irq = mx31ads_init_irq,
.init_time = mx31ads_timer_init,
.init_machine = mx31ads_init,
.restart = mxc_restart,
MACHINE_END
The machine_desc structure is found in arch.h. You don't need to add all the elements as they won't be called if not present. The kernel init looks a the machine ATAG and iterates through the sections to match the machine that the boot loader passes in. Locating the machine_desc is done in assembler very early in the linux boot.
I am trying to get Rsyslog's imfile plugin working without
any real success.
Here is useful OS version information:
# cat /etc/centos-release
CentOS Linux release 7.1.1503 (Core)
And here is Rsyslog version information:
# rsyslogd -v
rsyslogd 7.4.7, compiled with:
FEATURE_REGEXP: Yes
FEATURE_LARGEFILE: No
GSSAPI Kerberos 5 support: Yes
FEATURE_DEBUG (debug build, slow code): No
32bit Atomic operations supported: Yes
64bit Atomic operations supported: Yes
Runtime Instrumentation (slow code): No
uuid support: Yes
See http://www.rsyslog.com for more information.
I tried both legacy and RainerScript format of the configuration.
None of them works for me, sadly. I must be doing something completely wrong
but I simply can not decide on what it could be.
Here is my actual testing configuration (in RainerScript, the
former legacy version I tested was exactly the same in it's meaning):
# cat /etc/rsyslog.conf
global(
workDirectory = "/tmp"
)
module(
load = "imuxsock"
)
module(
load = "imjournal"
stateFile = "journal.state"
)
module(
load = "imfile"
pollingInterval = "10"
)
ruleset(name = "test-ruleset") {
if $syslogtag contains "test-syslogtag" then {
action(
type = "omfile"
file = "/tmp/test-file.log"
)
stop
}
}
input(
type = "imfile"
tag = "test-syslogtag"
stateFile = "test-input.state"
facility = "daemon"
severity = "debug"
file = "/tmp/test-input.in"
ruleset = "test-ruleset"
)
if prifilt("*.*") then {
action(
type = "omfile"
file = "/tmp/rsyslog-testing.log"
)
}
No warning nor error are produced by the Rsyslog with the above
configuration but also nothing from the /tmp/test-input.in file
is copied to the /tmp/test-file.log.
(I also double-checked the /var/log/audit/audit.log, of course, and ...
nothing suspicious is there. Being desperate on what's going on, I also
tried to setenforce 0 to switch SELinux off completely and to restart
the Rsyslog afterwards. It did not helped so the root cause of the problem
may not be SELinux-related issue.)
Also, the test-input.state file is correctly created in the global
workDirectory path (/tmp in this testing case). I also tried
standard paths (logs in /var/log, state file in /var/lib/rsyslog)
and it does not work either although all related files were created properly.
What's weird: I can not see any change in the state file if I populate the
input log file with some testing data even after Rsyslog restart using
# systemctl restart rsyslog (it should update the state file by default).
Just to point out: the imjournal and imuxsock plugins work and populate the fallback log file /tmp/rsyslog-testing.log correctly. Also
manually running Rsyslog on foreground with -D and/or -d options
did not helped me much to clarify why the imfile plugin does not work
for me in this particular configuration.
So, could you please
check my RainerScript syntax whether there is no obvious fault (I guess there is no such),
show me some working imfile plugin configuration on EL7?
Thank you very much.
--
mjf
With a few minor changes it finaly started to work properly. I think the
main root cause of the problem in my case must have been my testing it in
the /tmp directory where Rsyslog does not seem to work properly for some
reason on CentOS 7.
(May it be the /tmp is populated by the File System Namespace even
despite the fact that Systemd option PrivateTmp is not set to true in
the Rsyslog unit file and this option should be set to false by
default according to the Systemd manual page? This is higly unprobable, but
I haven't managed myself to dig more further into it yet. If I find it out,
I will update this answer.)
The other minor cause might have been incorrect filter written in
RainerScript (my real testing instance contained a horrible typo I
simply over-looked). So here is the resulting testing configuration that
works like charm for me.
# cat /etc/rsyslog.conf
global(
workDirectory = "/var/lib/rsyslog"
)
module(
load = "imuxsock"
)
module(
load = "imjournal"
stateFile = "journal.state"
)
module(
load = "imfile"
pollingInterval = "10"
)
ruleset(name = "test-ruleset") {
if $programname == "test-syslogtag" then {
action(
type = "omfile"
file = "/var/log/test-file.log"
)
stop
}
}
input(
type = "imfile"
tag = "test-syslogtag:"
stateFile = "test-input.state"
facility = "daemon"
severity = "debug"
file = "/var/log/test-input.in"
ruleset = "test-ruleset"
)
if prifilt("*.*") then {
action(
type = "omfile"
file = "/var/log/rsyslog-testing.log"
)
}
A little hint for those not knowing it - the $syslogtag and the
$programname seem to be close relatives: $syslogtag := $programname ":".
You can easily find out all the $ prefixed variables you can match against
by using RSYSLOG_DebugFormat output template which is already compiled in.
I hope it helps.
--
mjf
I am just beginning to develop a simple openssl engine. In this process, I referred to this nice website http://sinodun.com/2009/02/developing-an-engine-for-openssl/
I downloaded openssl 1.0.0c and compiled in my own folder as follows:
./config --prefix=/home/workingDir/openssl --openssldir=/home/workingDir/openssl
make
make install
Then I proceeded to copy this simple_engine.c file and compiled it to simple_engine.o and then built shared library simple_engine.so.
These are found in 'workingDir'
After these steps, I changed the 2 openssl.cnf files available under openssl/apps and openssl1.0.0c/ main folders such that:
openssl_conf = openssl_def
[openssl_def]
engines = engines_section
[engines_section]
simple = simple_section
[simple_section]
engine_id = simple
dynamic_path = /home/workingDir/simple_engine.so
MODULE_PATH = /home/workingDir/simple_engine.so
init = 0
[req]
distinguished_name = req_distinguished_name
[req_distinguished_name]
After this I set the LD_LIBRARY_PATH to point to /home/workingDir
Then when I did:
./openssl engine
I get the following error:
Error configuring OpenSSL
3076019848:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:185:filename(/home/workingDir/simple_engine.so): /home/workingDir/simple_engine.so: undefined symbol: ENGINE_get_static_state
3076019848:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244:
3076019848:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:450:
3076019848:error:260BC066:engine routines:INT_ENGINE_CONFIGURE:engine configuration error:eng_cnf.c:204:section=simple_section, name=dynamic_path, value=/home/workingDir/simple_engine.so
3076019848:error:0E07606D:configuration file routines:MODULE_RUN:module initialization error:conf_mod.c:235:module=engines, value=engines_section, retcode=-1
What is the problem? Please help. I am unable to proceed and don't find any documentation.
Thanks
The problem was the MODULE_PATH in the openssl.cnf. When I removed it , it works after recompiling the openssl with shared libs!
I want to develop a simple C application for learning purposes using Eclipse (Juno) CDT.
For that, I created the sample project provided in the IDE that creates a simple Hello World executable.
But when I want to build the project, the following errors comes up:
make: all
make: Error -- Could not find configuration file /etc/startup.mk
What does this mean? I can't find a file named like this anywhere on my system. Curiously enough, it works on my OS X with the same setup perfectly. Just not on my Windows machine.
What is going wrong here?
Edit: make -V show the following output:
D:\>make -V
make - Version 7.0 build 1182
Built-in Rules (cannot be changed):
OS:=NT
.IMPORT .IGNORE : ROOTDIR
.MAKEFILES:makefile
.SOURCE : .NULL
#B = $(#:b)
#D = $(#:d)
#F = $(#:f)
%B = $(%:b)
%D = $(%:d)
%F = $(%:f)
*B = $(*:b)
*D = $(*:d)
*F = $(*:f)
<B = $(<:b)
<D = $(<:d)
<F = $(<:f)
?B = $(?:b)
?F = $(?:f)
?D = $(?:d)
System Configuration:
SWITCHAR = /
OSVERSION = 01
OSRELEASE = 5
DIRSEPSTR = /\:
SHELL = /mksnt/sh.exe
SHELLFLAGS = /c
SHELLMETAS =
GROUPSHELL = /mksnt/sh.exe
GROUPFLAGS =
GROUPSUFFIX =
MAKEDIR = D:/
PWD = D:/
The make executable that is in your path is not the GNU make that eclipse expects and needs. It is probably a tool that comes with some other product -- make is a pretty common name. If your windows is not too old, you could try where make to locate the culprit and remove it from your path. Once you have done that, eclipse will be able to the GNU make by itself if you used the standard installation of your toolchain, or you could add it to your path. Alternatively, you can customize the eclipse build settings and explicitly point it to the make you want to use.
The make you want is probably in C:\MinGW\msys\1.0\bin, but could be somewhere else depending on how you installed the toolchain. There is also a mingw32-make in C:\MinGW\bin -- all assuming that you are using MinGW