ERROR: Patch can't be applied/reverted successfully - security

I've gotten
PATCH_SUPEE-5344_CE_1.8.0.0_v1-2015-02-10-08-10-38.sh
to install properly, but when I try to install
PATCH_SUPEE-1533_EE_1.13.x_v1-2015-02-10-08-18-32.sh
I get the error,
Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.
patching file app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php.rej
patching file app/code/core/Mage/Adminhtml/controllers/DashboardController.php
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file app/code/core/Mage/Adminhtml/controllers/DashboardController.php.rej
I'm using this command,
sh PATCH_SUPEE-1533_EE_1.13.x_v1-2015-02-10-08-18-32.sh
What do I need to do differently? This is super frustrating; any help is much appreciated!

This is what I did: I noticed it ask for confirmation "Assume -R? [n]" so I added the -R to confirm the action like this.
sh PATCH_SUPEE-5344_CE_1.8.0.0_v1-2015-02-10-08-10-38.sh -R
sh PATCH_SUPEE-1533_EE_1.13.x_v1-2015-02-10-08-18-32.sh -R
And they both came out successfully.
Checking if patch can be applied/reverted successfully...
Patch was applied/reverted successfully.
I hope this helps.

Which version you are using , because
PATCH_SUPEE-1533_EE_1.13.x_v1-2015-02-10-08-18-32.sh patch is already there in Magento 1.9.0.1
One can manually check these files also , with (-) sign - in file they have remove the code and with (+) - they have added new code
__PATCHFILE_FOLLOWS__
diff --git app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php
index c698108..6e256bb 100644
--- app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php
+++ app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php
## -444,7 +444,7 ## class Mage_Adminhtml_Block_Dashboard_Graph extends Mage_Adminhtml_Block_Dashboar
}
return self::API_URL . '?' . implode('&', $p);
} else {
- $gaData = urlencode(base64_encode(serialize($params)));
+ $gaData = urlencode(base64_encode(json_encode($params)));
$gaHash = Mage::helper('adminhtml/dashboard_data')->getChartDataHash($gaData);
$params = array('ga' => $gaData, 'h' => $gaHash);
return $this->getUrl('*/*/tunnel', array('_query' => $params));
diff --git app/code/core/Mage/Adminhtml/controllers/DashboardController.php app/code/core/Mage/Adminhtml/controllers/DashboardController.php
index eebb471..f9cb8d2 100644
--- app/code/core/Mage/Adminhtml/controllers/DashboardController.php
+++ app/code/core/Mage/Adminhtml/controllers/DashboardController.php
## -92,7 +92,8 ## class Mage_Adminhtml_DashboardController extends Mage_Adminhtml_Controller_Actio
if ($gaData && $gaHash) {
$newHash = Mage::helper('adminhtml/dashboard_data')->getChartDataHash($gaData);
if ($newHash == $gaHash) {
- if ($params = unserialize(base64_decode(urldecode($gaData)))) {
+ $params = json_decode(base64_decode(urldecode($gaData)), true);
+ if ($params) {
$response = $httpClient->setUri(Mage_Adminhtml_Block_Dashboard_Graph::API_URL)
->setParameterGet($params)
So if the code is already there in files as suggested above , your patch will not work as it's not needed actually.

Are you using Debian ? If so, try this:
./PATCH_SUPEE-1533_EE_1.13.x_v1-2015-02-10-08-18-32.sh
So sh command changed to ./
Don't forget to login as a file owner.

Related

fortran: Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(8)/INTEGER(2))

I am a beginner of Fortran and running a model written by Fortran. When I tried to compile it, I got an error message like:
libtool: link: (cd ".libs" && rm -f "libgrib_api_f77.so" && ln -s "libgrib_api_f77.so.1.0.0" "libgrib_api_f77.so")
libtool: link: ar cru .libs/libgrib_api_f77.a grib_fortran.o grib_f77.o
libtool: link: ranlib .libs/libgrib_api_f77.a
libtool: link: ( cd ".libs" && rm -f "libgrib_api_f77.la" && ln -s "../libgrib_api_f77.la" "libgrib_api_f77.la" )
gfortran -c -o same_int_long.o same_int_long.f90
same_int_long.f90:23:18:
17 | call check_long(x2(1),x2(2),ret)
| 2
......
23 | call check_long(x4(1),x4(2),ret)
| 1
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/INTEGER(2)).
same_int_long.f90:29:18:
17 | call check_long(x2(1),x2(2),ret)
| 2
......
29 | call check_long(x8(1),x8(2),ret)
| 1
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(8)/INTEGER(2)).
same_int_long.f90:51:17:
45 | call check_int(x2(1),x2(2),ret)
| 2
......
51 | call check_int(x4(1),x4(2),ret)
| 1
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/INTEGER(2)).
same_int_long.f90:57:17:
45 | call check_int(x2(1),x2(2),ret)
| 2
......
57 | call check_int(x8(1),x8(2),ret)
| 1
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(8)/INTEGER(2)).
make[2]: *** [Makefile:546: same_int_long.o] Error 1
make[2]: Leaving directory '/gpfs/home3/eccei339/snellius_surfex/open_SURFEX_V8_1/src/LIB/grib_api-1.17.0-Source/fortran'
make[1]: *** [Makefile:604: all-recursive] Error 1
make[1]: Leaving directory '/gpfs/home3/eccei339/snellius_surfex/open_SURFEX_V8_1/src/LIB/grib_api-1.17.0-Source'
make: *** [Makefile:398: /home/eccei339/snellius_surfex/open_SURFEX_V8_1/src/LIB/grib_api-1.17.0-Source-LXgfortran/include/grib_api.mod] Error 2
What I did is basically following the installation of the model:
Step1
(base) [eccei339#int3 ~]$ mkdir snellius_surfex
(base) [eccei339#int3 ~]$ cp open_surfex_v8_1_20200107.tar-2.gz snellius_surfex/
(base) [eccei339#int3 ~]$ cd snellius_surfex/
(base) [eccei339#int3 snellius_surfex]$ tar zxvf open_surfex_v8_1_20200107.tar-2.gz
…(omit the tar zxvf logging information)
Step 2: some essential env variable
(base) [eccei339#int3 snellius_surfex]$ export VER_MPI="NOMPI"
(base) [eccei339#int3 snellius_surfex]$ export OMP_NUM_THREADS=1
(base) [eccei339#int3 snellius_surfex]$ module load 2021
(base) [eccei339#int3 snellius_surfex]$ module load GCC/10.3.0
(base) [eccei339#int3 snellius_surfex]$ ls
open_SURFEX_V8_1 open_surfex_v8_1_20200107.tar-2.gz
(here I exported some necessary envi var following the instructions of installation of the software)
Step 3: configure
(base) [eccei339#int3 snellius_surfex]$ cd open_SURFEX_V8_1/src/
(base) [eccei339#int3 src]$ ls
ASSIM Makefile Rules.bullXI15.mk Rules.MCgfortran.mk SURFEX
configure Makefile.SURFEX.mk Rules.bullXI16.mk Rules.SX8.mk
FORC OFFLIN Rules.LXgfortran.mk Rules.zgfortran.mk
include Rules.AIX64.mk Rules.LXifort.mk Rules.zifort.mk
LIB Rules.bgfortran.mk Rules.LXpgi.mk scripts
(base) [eccei339#int3 src]$ ./configure
(omit the long logging info of the “configure” command)
(base) [eccei339#int3 src]$ . ../conf/profile_surfex-LXgfortran-SFX-V8-1-1-NOMPI-OMP-O2-X0
(an essential step following the instructions of installation of the software)
Step 4: make the master
(base) [eccei339#int3 src]$ make
find: ‘/home/eccei339/snellius_surfex/open_SURFEX_V8_1/src/dir_obj-LXgfortran-SFX-V8-1-1-NOMPI-OMP-O2-X0/MASTER’: No such file or directory
cd /home/eccei339/snellius_surfex/open_SURFEX_V8_1/src/LIB/grib_api-1.17.0-Source && LDFLAGS= FCFLAGS= CPPFLAGS="" \
./configure --disable-jpeg --prefix=/home/eccei339/snellius_surfex/open_SURFEX_V8_1/src/LIB/grib_api-1.17.0-Source-LXgfortran FC="gfortran" && \
make -j 1 clean && \
make -j 1 && \
make -j 1 install && \
make -j 1 clean
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking how to print strings... printf
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
(omit the long logging information, and the final lines are the error message shown in the beginning of this question description.)
I searched the Internet that this could be due to the GCC 10 is more strict than older GCC (I compiled this model last year with older GCC and made it, but failed this time because our server is transferred to a new system, thus the GCC is upgraded from older version to a new version). Some information from Google said that I could add something like this:
export FCFLAGS="-w -fallow-argument-mismatch -O2"
export FFLAGS="-w -fallow-argument-mismatch -O2"
But I tried it in the step 2 where I export some essential environmental variables, it still does not work. So I am wondering is there anybody who can help me? Thanks a lot!
Updates: the source code of grib_api-1.17.0-Source/fortran/same_int_long.f90 from http://distfiles.macports.org/grib_api/ is as following:
! Copyright 2005-2016 ECMWF.
!
! This software is licensed under the terms of the Apache Licence Version 2.0
! which can be obtained at http://www.apache.org/licenses/LICENSE-2.0.
!
! In applying this licence, ECMWF does not waive the privileges and immunities granted to it by
! virtue of its status as an intergovernmental organisation nor does it submit to any jurisdiction.
integer function kind_of_long()
integer(2), dimension(2) :: x2 = (/1, 2/)
integer(4), dimension(2) :: x4 = (/1, 2/)
integer(8), dimension(2) :: x8 = (/1, 2/)
character(len=1) :: ret
kind_of_long=-1
call check_long(x2(1),x2(2),ret)
if (ret == 't') then
kind_of_long=2
return
endif
call check_long(x4(1),x4(2),ret)
if (ret == 't') then
kind_of_long=4
return
endif
call check_long(x8(1),x8(2),ret)
if (ret == 't') then
kind_of_long=8
return
endif
end function kind_of_long
integer function kind_of_int()
integer(2), dimension(2) :: x2 = (/1, 2/)
integer(4), dimension(2) :: x4 = (/1, 2/)
integer(8), dimension(2) :: x8 = (/1, 2/)
character(len=1) :: ret
kind_of_int=-1
call check_int(x2(1),x2(2),ret)
if (ret == 't') then
kind_of_int=2
return
endif
call check_int(x4(1),x4(2),ret)
if (ret == 't') then
kind_of_int=4
return
endif
call check_int(x8(1),x8(2),ret)
if (ret == 't') then
kind_of_int=8
return
endif
end function kind_of_int
program same_int_long
integer ki,kl
ki=kind_of_int()
kl=kind_of_long()
if (ki /= kl) then
write (*,'(i1)') 0
else
write (*,'(i1)') 1
endif
end program same_int_long
Here is the full log information of make: https://drive.google.com/file/d/14rkj2ay39Rv84QBL6UDiSdlIAfhuEt_z/view?usp=sharing
This appened to me with a MPI fortran code. The cause is a decision from gcc developpers on what should be «good interfaces» see here.
Two solutions in my case :
Tells gfortran to ignore this concerns with option -fallow-argument-mismatch.
Use modern fortran interface (use mpi instead of include mpif.h)
I chose the latter.
What you are instantiating as an INTEGER is getting its value assigned by another (variable or declaration) integer of a different "byte" memory storage size.
e.g. in other languages int is 4 bytes and long is 8 bytes. (note) Fortran also has pointers alike C/C++
https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vna5/index.html
nb: You did not show the code that has the problem , somewhere around line 29 char 18 in source file same_int_long.f90 ??

Integrating Crashpad with Qt on Linux

I am trying to integrate Crashpad into Qt application on Linux. I am using Bugsplat database for testing and I followed this tutorial and managed to build this "dummy" application, which should serve as an example of using Qt with Crashpad.
I have made minor adjustments of files to fix build for my Linux platform, primarily making change of version easier and fixed creating directory & crashpad files next to application binaries.
All of the changes are listed below as a diff file:
diff --git a/Crashpad/Tools/Linux/symbols.sh b/Crashpad/Tools/Linux/symbols.sh
index 095f295..b065438 100644
--- a/Crashpad/Tools/Linux/symbols.sh
+++ b/Crashpad/Tools/Linux/symbols.sh
## -3,6 +3,6 ## symupload="${1}/Crashpad/Tools/Linux/symupload"
app="${2}/${4}.debug"
sym="${4}.sym"
url="https://${3}.bugsplat.com/post/bp/symbol/breakpadsymbols.php?appName=${4}&appVer=${5}"
-
+echo ${url}
eval "${dump_syms} ${app} > ${sym}"
eval $"${symupload} \"${sym}\" \"${url}\""
diff --git a/main.cpp b/main.cpp
index db97dd4..b721dc5 100644
--- a/main.cpp
+++ b/main.cpp
## -26,7 +26,7 ## int main(int argc, char *argv[])
{
QString dbName = "Fred";
QString appName = "myQtCrasher";
- QString appVersion = "1.0";
+ QString appVersion = QString::number(MAJOR_VERSION) + "." + QString::number(MINOR_VERSION);
initializeCrashpad(dbName, appName, appVersion);
diff --git a/myQtCrasher.pro b/myQtCrasher.pro
index 3005e41..3bf7a3e 100644
--- a/myQtCrasher.pro
+++ b/myQtCrasher.pro
## -15,6 +15,12 ## DEFINES += QT_DEPRECATED_WARNINGS
# You can also select to disable deprecated APIs only up to a certain version of Qt.
#DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000 # disables all the APIs deprecated before Qt 6.0.0
+MAJOR_VERSION = 4
+MINOR_VERSION = 9
+
+DEFINES += MAJOR_VERSION=$$MAJOR_VERSION
+DEFINES += MINOR_VERSION=$$MINOR_VERSION
+
SOURCES += \
main.cpp \
mainwindow.cpp \
## -94,7 +100,8 ## linux {
LIBS += -L$$PWD/Crashpad/Libraries/Linux/ -lbase
# Copy crashpad_handler to build directory and run dump_syms and symupload
- QMAKE_POST_LINK += "cp $$PWD/Crashpad/Bin/Linux/crashpad_handler $$OUT_PWD/crashpad"
- QMAKE_POST_LINK += "&& bash $$PWD/Crashpad/Tools/Linux/symbols.sh $$PWD $$OUT_PWD fred myQtCrasher 1.0 > $$PWD/Crashpad/Tools/Linux/symbols.out 2>&1"
- QMAKE_POST_LINK += "&& cp $$PWD/Crashpad/attachment.txt $$OUT_PWD/attachment.txt"
+ QMAKE_POST_LINK += "mkdir $$OUT_PWD/crashpad"
+ QMAKE_POST_LINK += "&& cp $$PWD/Crashpad/Bin/Linux/crashpad_handler $$OUT_PWD/crashpad"
+ QMAKE_POST_LINK += "&& bash $$PWD/Crashpad/Tools/Linux/symbols.sh $$PWD $$OUT_PWD fred myQtCrasher $$MAJOR_VERSION"."$$MINOR_VERSION > $$PWD/Crashpad/Tools/Linux/symbols.out 2>&1"
+# QMAKE_POST_LINK += "&& cp $$PWD/Crashpad/attachment.txt $$OUT_PWD/attachment.txt" #if any attachment is needed
}
Build generates both myQtCrasher.debug, and externaly generated myQtCrasher.sym symbols file.
Using their dummy database (the creditals are fred#bugsplat.com and Flintstone as a password), I have managed to report crash, but I for some reason, the bug do not contain uploaded symbols. I have tried to manualy upload them using dump_syms and then symupload applications by sending request onto https://fred.bugsplat.com/post/bp/symbol/breakpadsymbols.php?appName=myQtCrasher&appVer=4.9, but without success.
The symupload application output is
Failed to open curl lib from binary, use libcurl.so instead
Successfully sent the symbol file.
How can I properly upload *.sym and view stack trace on crash?
Thanks for your help!
We were able to get the symbols to resolve for this crash report. Right after the symupload warning Failed to open curl lib from binary, use libcurl.so instead it says successfully sent the symbol file. I confirmed the symbol file was uploaded correctly.
I found 2 issues with the symbol file. When minidump_stackwalk was looking for the corresponding symbols it was looking for:
/myQtCrasher-4.9/myQtCrasher/C03D64A46AB29A093459A592482836E50/myQtCrasher.sym
The file that was uploaded to BugSplat was myQtCrasher.debug.sym and the module on the first line of the sym file was myQtCrasher.debug. I changed the file name to myQtCrasher.sym and the module name to myQtCrasher and the symbols for the myQtCrasher stack frames displayed function names and line numbers.
I'm not sure if these issues with mismatched symbols were due to your script changes but it seems like our script attempts to set the following variables:
app="${2}/${4}.debug"
sym="${4}.sym"
Therefore the script expects the user to generate sym files from the .debug file, but name them based on the corresponding executable.

Cannot update Yocto Bitbake Recipe for Bzip2 from 1.0.6 to 1.0.7 for CVE-2019-12900 for Nvidia Jetson Nano

On Ubuntu 18.04 I am trying to build a Yocto SD Card Image for the Nvidia Jetson Nano using the "meta-tegra" layer. I ran into the recent bzip2 issue that requires the latest bzip2 ( 1.0.7 ) to fix as detailed in these forum posts:
https://devtalk.nvidia.com/default/topic/1056301/b/t/post/5355418/
https://devtalk.nvidia.com/default/topic/1056381/jetson-agx-xavier/jetpack-4-2-xavier-install-failed/1
I found the latest bzip2 source here:
https://www.sourceware.org/bzip2/downloads.html
I tried playing with ${WORKDIR}, ${S}, do_compile_append, and do_install_append, however I keep getting errors related to the wrong source directory. I basically took the OE Bzip2 1.0.6 recipe and change the version source and checksums.
Please help me fix this build issue with yocto - thanks!
Bitbake Failure:
Initialising tasks: 100% |##########################################################################| Time: 0:00:00
Sstate summary: Wanted 382 Found 0 Missed 382 Current 45 (0% match, 10% complete)
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: bzip2-native-1.0.7-r5 do_compile: oe_runmake failed
ERROR: bzip2-native-1.0.7-r5 do_compile: Function failed: do_compile (log file is located at /home/ubuntu/Desktop/mts-jetson-yocto/build/tmp/work/x86_64-linux/bzip2-native/1.0.7-r5/temp/log.do_compile.115964)
ERROR: Logfile of failure stored in: /home/ubuntu/Desktop/mts-jetson-yocto/build/tmp/work/x86_64-linux/bzip2-native/1.0.7-r5/temp/log.do_compile.115964
Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 128
| make: *** No targets specified and no makefile found. Stop.
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at /home/ubuntu/Desktop/mts-jetson-yocto/build/tmp/work/x86_64-linux/bzip2-native/1.0.7-r5/temp/log.do_compile.115964)
ERROR: Task (virtual:native:/home/ubuntu/Desktop/mts-jetson-yocto/layers/meta-mts/recipes-extended/bzip2/bzip2_1.0.7.bb:do_compile) failed with exit code '1'
Second Keyboard Interrupt, stopping...
Summary: 1 task failed:
virtual:native:/home/ubuntu/Desktop/mts-jetson-yocto/layers/meta-mts/recipes-extended/bzip2/bzip2_1.0.7.bb:do_compile
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
Current Broken Bitbake recipe:
SECTION = "console/utils"
LICENSE = "bzip2"
LIC_FILES_CHKSUM = "file://LICENSE;beginline=4;endline=37;md5=39406315f540c69bd05b1531daedd2ae"
PR = "r5"
SRC_URI = "https://www.sourceware.org/pub/bzip2/bzip2-1.0.7.tar.gz \
"
#WORKDIR = "${WORKDIR}/bzip-1.0.7"
#WORKDIR = "${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}/bzip2-1.0.7"
#S = "${WORKDIR}/bzip2-1.0.7"
#do_compile_prepend() {
# cd ../
#}
#do_install_prepend() {
# cd ../
#}
SRC_URI[md5sum] = "1a6a61cc867be4f3d6549037a09bf13e"
SRC_URI[sha256sum] = "e768a87c5b1a79511499beb41500bcc4caf203726fff46a6f5f9ad27fe08ab2b"
UPSTREAM_CHECK_URI = "https://www.sourceware.org/bzip2/"
UPSTREAM_VERSION_UNKNOWN = "1"
PACKAGES =+ "libbz2"
CFLAGS_append = " -fPIC -fpic -Winline -fno-strength-reduce -D_FILE_OFFSET_BITS=64"
inherit autotools update-alternatives ptest relative_symlinks
ALTERNATIVE_PRIORITY = "100"
ALTERNATIVE_${PN} = "bunzip2 bzcat bzip2"
#install binaries to bzip2-native under sysroot for replacement-native
EXTRA_OECONF_append_class-native = " --bindir=${STAGING_BINDIR_NATIVE}/${PN}"
do_install_ptest () {
sed -i -e "s|^Makefile:|_Makefile:|" ${D}${PTEST_PATH}/Makefile
}
FILES_libbz2 = "${libdir}/lib*${SOLIBS}"
PROVIDES_append_class-native = " bzip2-replacement-native"
BBCLASSEXTEND = "native nativesdk"
#addtask fix_path before do_compile
Two ideas:
Just apply the patch for the security issue, much easier. This patch is already on the oe-core list.
Take the upgrade patch that is also on the list

how to remove vendor name from crosstool-ng toolchain name

How do I configure crosstool-ng to drop the vendor name from the generated toolchain name.
For example to create an arm cross toolchain without specifying a vendor part would result in the following naming output
arm-unknown-linux-gnueabihf-g++
If I had supplied a vendor for instance "linaro" then I would have an output such as
arm-linaro-linux-gnueabihf-g++
What I want is to make the crosstool-ng to output the name as follows
arm-linux-gnueabihf-g++
I am aware that you can use the "Tuple's sed transform" and the "Tuple's alias" these facilities from menuconfig but these only create symbolic links to the arm-unknown-gnueabihf-g++ etc.
I have a toolchain that came with a board I am playing with and these toolchain have the vendor's part omitted. So my question "How do they do that?"
Even if the documentation states that:
CT_TARGET_VENDOR: [...] It can be set to empty, to remove the vendor string from the target tuple.
(see http://crosstool-ng.github.io/docs/configuration/ )
The current behavior is to fall back to 'unknown' if no value for CT_TARGET_VENDOR is given.
This situation was discussed within the crosstool-ng mailing list back in 2011 and there was a patch provided with a solution which may help you.
The idea of the patch was to:
[...] supplies a fake vendor and
then strips it out afterwards.
within scripts/functions of the crosstool-ng source.
See: https://sourceware.org/ml/crossgcc/2011-10/msg00047.html
diff -r a31d097e28cd -r 5b1330e7264a scripts/functions
--- a/scripts/functions Wed Oct 19 15:27:32 2011 +1300
+++ b/scripts/functions Wed Oct 19 16:23:36 2011 +1300
## -944,6 +944,20 ##
fi
}
+# Computes the target tuple from the configuration and the supplied
+# vendor string
+CT_BuildOneTargetTuple() {
+ local vendor="${1}"
+ local target
+
+ target="${CT_TARGET_ARCH}"
+ target="${target}${vendor:+-${vendor}}"
+ target="${target}${CT_TARGET_KERNEL:+-${CT_TARGET_KERNEL}}"
+ target="${target}${CT_TARGET_SYS:+-${CT_TARGET_SYS}}"
+
+ echo "${target}"
+}
+
# Compute the target tuple from what is provided by the user
# Usage: CT_DoBuildTargetTuple
# In fact this function takes the environment variables to build the target
## -994,10 +1008,7 ##
CT_DoKernelTupleValues
# Finish the target tuple construction
- CT_TARGET="${CT_TARGET_ARCH}"
- CT_TARGET="${CT_TARGET}${CT_TARGET_VENDOR:+-${CT_TARGET_VENDOR}}"
- CT_TARGET="${CT_TARGET}${CT_TARGET_KERNEL:+-${CT_TARGET_KERNEL}}"
- CT_TARGET="${CT_TARGET}${CT_TARGET_SYS:+-${CT_TARGET_SYS}}"
+ CT_TARGET=$(CT_BuildOneTargetTuple "${CT_TARGET_VENDOR}")
# Sanity checks
__sed_alias=""
## -1012,7 +1023,14 ##
esac
# Canonicalise it
- CT_TARGET=$(CT_DoConfigSub "${CT_TARGET}")
+ if [ -n "${CT_TARGET_VENDOR}" ]; then
+ CT_TARGET=$(CT_DoConfigSub "${CT_TARGET}")
+ else
+ # Canonicalise with a fake vendor string then strip it out
+ local target=$(CT_BuildOneTargetTuple "CT_INVALID")
+ CT_TARGET=$(CT_DoConfigSub "${target}" |sed -r -s s:CT_INVALID-::)
+ fi
+
# Prepare the target CFLAGS
CT_ARCH_TARGET_CFLAGS="${CT_ARCH_TARGET_CFLAGS} ${CT_ARCH_ENDIAN_CFLAG}"
CT_ARCH_TARGET_CFLAGS="${CT_ARCH_TARGET_CFLAGS} ${CT_ARCH_ARCH_CFLAG}"

node.js filesystem mangles Cygwin drive name

I recently installed Cygwin64 after using Cygwin32 for quite some time and I'm now having problems with one of our production scripts. Node.js's 'readFileSync' seems to be prepending the windows drive letter to the path and then failing to resolve - e.g. /cygdrive/c/foo becomes c:/cygdrive/c/foo.
I've found various mentions of similar issues online but so far I've been unable to resolve this problem. My co-worker has a seemingly identical setup and does not experience the problem.
Here it is in a nutshell -
$ cat filetest.js
var fs = require('fs');
function main(argv) {
console.log("fileName => ", argv[2]);
var data = fs.readFileSync(argv[2], 'utf8');
console.log("success");
}
main(process.argv);
$ s/node filetest.js filetest.js
fileName => filetest.js
success
$ ls -l /cygdrive/c/temp/Test.txt
----rwx---+ 1 bdodd Domain Users 14 Jun 3 14:12 /cygdrive/c/temp/Test.txt
$ s/node filetest.js /cygdrive/c/temp/Test.txt
fileName => /cygdrive/c/temp/Test.txt
fs.js:338
return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
^
Error: ENOENT, no such file or directory 'C:\cygdrive\c\temp\Test.txt'
and just for completeness...
$ cat /etc/fstab
# /etc/fstab
#
# This file is read once by the first process in a Cygwin process tree.
# To pick up changes, restart all Cygwin processes. For a description
# see https://cygwin.com/cygwin-ug-net/using.html#mount-table
# This is default anyway:
none /cygdrive cygdrive binary,posix=0,user 0 0
$ cd /cygdrive/
$ ls -l
total 40
d---rwx---+ 1 NT SERVICE+TrustedInstaller NT SERVICE+TrustedInstaller 0 Jun 3 14:09 c
dr-xrwxr-x 1 Unknown+User Unix_Group+33 0 Apr 29 2014 u
Insight would be greatly appreciated. Thanks!

Resources