Re: [yocto] tmp on NFS
I can think of various things that would go wrong with tmp on NFS. One of the most obvious example would be to try and change the network configuration while running, and needing some temporary file to manage that.\ I think the expectation is that /tmp should be accessible at all times, and that it's local and (at least somewhat) volatile. I tend to mount /tmp/ in RAM on all systems. Even my desktop. Not having to do wait for a device IO queue when performing actions in /tmp/ can greatly improve the responsiveness of the system. If your application's /tmp/ storage requirements are such that they don't fit in RAM, I don't think /tmp/ is the place where they should be stored. On 07-10-15 03:37, Luke (Lucas) Starrett wrote: Hi, Can anybody give a brief history of time on why using an NFS drive for tmp is necessarily a bad thing, and why we have a sanity check for it? We’re doing this without any obvious side effects. I’m aware of the checks added by changes like this: patchwork.openembedded.org/patch/61107/ However, I don’t see the reasoning/background documented as to exactly what is actually broken when putting tmp on NFS. Is it time skew, problems with concurrent file access, something else? Thanks, Luke Kind regards, Mike Looijmans System Expert TOPIC Embedded Products Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 Telefax: +31 (0) 499 33 69 70 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] tmp on NFS
I should clarify, the sanity check warning I'm referring to is about the Yocto build/tmp directory not /tmp as in the system level tmp dir. Thanks, Luke. -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Mike Looijmans Sent: Wednesday, October 07, 2015 3:01 AM To: yocto@yoctoproject.org Subject: Re: [yocto] tmp on NFS I can think of various things that would go wrong with tmp on NFS. One of the most obvious example would be to try and change the network configuration while running, and needing some temporary file to manage that.\ I think the expectation is that /tmp should be accessible at all times, and that it's local and (at least somewhat) volatile. I tend to mount /tmp/ in RAM on all systems. Even my desktop. Not having to do wait for a device IO queue when performing actions in /tmp/ can greatly improve the responsiveness of the system. If your application's /tmp/ storage requirements are such that they don't fit in RAM, I don't think /tmp/ is the place where they should be stored. On 07-10-15 03:37, Luke (Lucas) Starrett wrote: > Hi, > > Can anybody give a brief history of time on why using an NFS drive for tmp is > necessarily a bad thing, and why we have a sanity check for it? We’re doing > this without any obvious side effects. > > I’m aware of the checks added by changes like this: > > patchwork.openembedded.org/patch/61107/ > > However, I don’t see the reasoning/background documented as to exactly what is > actually broken when putting tmp on NFS. Is it time skew, problems with > concurrent file access, something else? > > Thanks, > > Luke > > > Kind regards, Mike Looijmans System Expert TOPIC Embedded Products Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 Telefax: +31 (0) 499 33 69 70 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] tmp on NFS
On 7 October 2015 at 02:37, Luke (Lucas) Starrett wrote: > I’m aware of the checks added by changes like this: > > > > patchwork.openembedded.org/patch/61107/ > > > > However, I don’t see the reasoning/background documented as to exactly > what is actually broken when putting tmp on NFS. Is it time skew, problems > with concurrent file access, something else? > Follow the link in the patch to the referenced bug, and comment #8 by Mark Hatle explains the problems that Wind River were seeing in testing: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5442#c8 (background: a lot of the sanity tests are from Wind River who appear to have a pathological need to break software: what happens if I do a build nested 20 directories deep, what happens if I've a space in the build directory name, and so on) Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] tmp on NFS
On 7 October 2015 at 13:59, Burton, Ross wrote: > Follow the link in the patch to the referenced bug, and comment #8 by Mark > Hatle explains the problems that Wind River were seeing in testing: > I should also add that many people buy lots of RAM and do builds with build/tmp in a tmpfs as it gives you a noticeable performance increase, so I dread to think how much it will hurt to do a build with build/tmp on a network mount. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] tmp on NFS
On 07-10-15 15:04, Burton, Ross wrote: On 7 October 2015 at 13:59, Burton, Ross mailto:ross.bur...@intel.com>> wrote: Follow the link in the patch to the referenced bug, and comment #8 by Mark Hatle explains the problems that Wind River were seeing in testing: I should also add that many people buy lots of RAM and do builds with build/tmp in a tmpfs as it gives you a noticeable performance increase, so I dread to think how much it will hurt to do a build with build/tmp on a network mount. Telling Ubuntu to actually use all that RAM for some serious caching (e.g. allow 50% dirty pages, and extend the timeout to several minutes), and (if you have >14) putting cfq back into its rightful place as io scheduler made a huge difference for me. Kind regards, Mike Looijmans System Expert TOPIC Embedded Products Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 Telefax: +31 (0) 499 33 69 70 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] packagegroup not appearing in HOB
Hello, I created a packagegroup file as per the instructions called packagegroup-foo.bb Within that file I define 2 package groups as such. PACKAGES = "\ packagegroup-foo-apps \ packagegroup-foo-tools \ " RDEPENDS_packagegroup-foo-apps = "…" RDEPENDS_packagegroup-foo-tools = "…" However, when I run HOB and inspect the list of packages it shows packagegroup-foo but it does not list packagegroup-foo-apps or packagegroup-foo-tools. Is this correct? How do I verify the groups are created correctly so I can complete implementation using the new group definitions? TIA -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] svn fetch problem?
Hello, I am fetching my source code from SVN in my recipe file. The build works fine. However if I open a "devshell", the .svn directory is missing so I can not checkin any modifications. I looked at svn.py and it looks like it should be doing a checkout operation. How do I fix this? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] svn fetch problem?
The build system creates a tar.gz file from the SVN checkout. Probally the devshell opens on this .tar.gz exploded, not at the folder checked out. What I do is checkout manunally and use toolchain to compile. So I do fix/compile/test cycle on my own workcopy and using toolchains provided by Yocto. Then I copy the binaries/libraries to target manually and test it. Once everything is fine I test the build inside Yocto. Cheers, 2015-10-07 15:49 GMT-03:00 Allen Curtis : > Hello, > > I am fetching my source code from SVN in my recipe file. The build works > fine. However if I open a "devshell", the .svn directory is missing so I can > not checkin any modifications. I looked at svn.py and it looks like it should > be doing a checkout operation. > > How do I fix this? > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- "Do or do not. There is no try" Yoda Master -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-selinux][PATCH 1/1] refpolicy: SRCREV_FORMAT needed
Signed-off-by: Joe Slater
---
recipes-security/refpolicy/refpolicy_git.inc |1 +
1 file changed, 1 insertion(+)
diff --git a/recipes-security/refpolicy/refpolicy_git.inc
b/recipes-security/refpolicy/refpolicy_git.inc
index 6db4b9e..32b3195 100644
--- a/recipes-security/refpolicy/refpolicy_git.inc
+++ b/recipes-security/refpolicy/refpolicy_git.inc
@@ -3,6 +3,7 @@ SRC_URI +=
"git://github.com/TresysTechnology/refpolicy-contrib.git;protocol=git
SRCREV_refpolicy = "c8c2b8b0c80a59414aefc4d32fdd2e8152ea5af2"
SRCREV_refpolicy-contrib = "32c25f2d965569e18489913fbda5e0f0c6f90d51"
+SRCREV_FORMAT = "refpolicy.refpolicy-contrib"
FILESEXTRAPATHS_prepend := "${THISDIR}/refpolicy-git:"
--
1.7.9.5
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Can any one please tell the what is the exact difference between DEPENDS and RDEPENDS
Hi, Can any one please tell the what is the exact difference between DEPENDS and RDEPENDS . I am not able to get it . How these variables are exactly parsed. -regards vivek -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-selinux][PATCH 1/1] refpolicy: SRCREV_FORMAT needed
On 10/08/2015 07:36 AM, Joe Slater wrote:
Signed-off-by: Joe Slater
---
recipes-security/refpolicy/refpolicy_git.inc |1 +
1 file changed, 1 insertion(+)
diff --git a/recipes-security/refpolicy/refpolicy_git.inc
b/recipes-security/refpolicy/refpolicy_git.inc
index 6db4b9e..32b3195 100644
--- a/recipes-security/refpolicy/refpolicy_git.inc
+++ b/recipes-security/refpolicy/refpolicy_git.inc
@@ -3,6 +3,7 @@ SRC_URI +=
"git://github.com/TresysTechnology/refpolicy-contrib.git;protocol=git
SRCREV_refpolicy = "c8c2b8b0c80a59414aefc4d32fdd2e8152ea5af2"
SRCREV_refpolicy-contrib = "32c25f2d965569e18489913fbda5e0f0c6f90d51"
Hi Joe,
You may need to update your patch, upstream version has:
+SRCREV_refpolicy = "${AUTOREV}"
+SRCREV_refpolicy-contrib = "${AUTOREV}"
...
Thanks
Wenzong
+SRCREV_FORMAT = "refpolicy.refpolicy-contrib"
FILESEXTRAPATHS_prepend := "${THISDIR}/refpolicy-git:"
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/2][meta-selinux] remove packages: libcap-ng, swig
From: Wenzong Fan They have been added to oe-core. The following changes since commit 463f97bfd1180475540b7d91e3fec6a2b33966bd: audit/auvirt: get inline functions work with both gnu89 & gnu11 (2015-09-21 10:42:27 -0400) are available in the git repository at: git://git.pokylinux.org/poky-contrib wenzong/libcap http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/libcap Wenzong Fan (2): libcap-ng: remove package swig: remove package recipes-devtools/swig/swig.inc | 59 -- ...lf-exe-for-swig-swiglib-on-non-Win32-plat.patch | 69 -- ...nfigure-use-pkg-config-for-pcre-detection.patch | 65 recipes-devtools/swig/swig_2.0.10.bb | 11 recipes-security/libcap-ng/libcap-ng/python.patch | 58 -- recipes-security/libcap-ng/libcap-ng_0.7.7.bb | 40 - 6 files changed, 302 deletions(-) delete mode 100644 recipes-devtools/swig/swig.inc delete mode 100644 recipes-devtools/swig/swig/0001-Use-proc-self-exe-for-swig-swiglib-on-non-Win32-plat.patch delete mode 100644 recipes-devtools/swig/swig/0001-configure-use-pkg-config-for-pcre-detection.patch delete mode 100644 recipes-devtools/swig/swig_2.0.10.bb delete mode 100644 recipes-security/libcap-ng/libcap-ng/python.patch delete mode 100644 recipes-security/libcap-ng/libcap-ng_0.7.7.bb -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2][meta-selinux] libcap-ng: remove package
From: Wenzong Fan
libcap-ng 0.7.7 has been added to oe-core:
ad509d7644803ff9386affefe2ec1a3664027074
No change need to port.
Signed-off-by: Wenzong Fan
---
recipes-security/libcap-ng/libcap-ng/python.patch | 58 ---
recipes-security/libcap-ng/libcap-ng_0.7.7.bb | 40
2 files changed, 98 deletions(-)
delete mode 100644 recipes-security/libcap-ng/libcap-ng/python.patch
delete mode 100644 recipes-security/libcap-ng/libcap-ng_0.7.7.bb
diff --git a/recipes-security/libcap-ng/libcap-ng/python.patch
b/recipes-security/libcap-ng/libcap-ng/python.patch
deleted file mode 100644
index 59591eb..000
--- a/recipes-security/libcap-ng/libcap-ng/python.patch
+++ /dev/null
@@ -1,58 +0,0 @@
-From b01bb2694f66cd981e6d61523433dc3eb5ed32f2 Mon Sep 17 00:00:00 2001
-From: Li xin
-Date: Sat, 18 Jul 2015 23:03:30 +0900
-Subject: [PATCH] configure.ac - Avoid an incorrect check for python.
- Makefile.am - avoid hard coded host include paths.
-
-Upstream-Status: pending
-
-Signed-off-by: Mark Hatle
-Signed-off-by: Li Xin
- bindings/python/Makefile.am | 3 ++-
- configure.ac| 15 ++-
- 2 files changed, 4 insertions(+), 14 deletions(-)
-
-diff --git a/bindings/python/Makefile.am b/bindings/python/Makefile.am
-index 82b9bb8..f9fe7a8 100644
a/bindings/python/Makefile.am
-+++ b/bindings/python/Makefile.am
-@@ -23,7 +23,8 @@ SUBDIRS = test
- CONFIG_CLEAN_FILES = *.loT *.rej *.orig
- AM_CFLAGS = -fPIC -DPIC
- PYLIBVER ?= python$(PYTHON_VERSION)
--AM_CPPFLAGS = -I. -I$(top_builddir) -I@PYINCLUDEDIR@
-+PYINC ?= /usr/include/$(PYLIBVER)
-+AM_CPPFLAGS = -I. -I$(top_builddir) -I$(PYINC)
- LIBS = $(top_builddir)/src/libcap-ng.la
- SWIG_FLAGS = -python
- SWIG_INCLUDES = ${AM_CPPFLAGS}
-diff --git a/configure.ac b/configure.ac
-index 1d777d5..9d90f64 100644
a/configure.ac
-+++ b/configure.ac
-@@ -123,19 +123,8 @@ if test x$use_python = xno ; then
- else
- AC_MSG_RESULT(testing)
- AM_PATH_PYTHON
--PYINCLUDEDIR=`python${am_cv_python_version} -c "from distutils import
sysconfig; print(sysconfig.get_config_var('INCLUDEPY'))"`
--if test -f ${PYINCLUDEDIR}/Python.h ; then
-- python_found="yes"
-- AC_SUBST(PYINCLUDEDIR)
-- AC_MSG_NOTICE(Python bindings will be built)
--else
-- python_found="no"
-- if test x$use_python = xyes ; then
-- AC_MSG_ERROR([Python explicitly required and python headers
found])
-- else
-- AC_MSG_WARN("Python headers not found - python bindings will
not be made")
-- fi
--fi
-+python_found="yes"
-+AC_MSG_NOTICE(Python bindings will be built)
- fi
- AM_CONDITIONAL(HAVE_PYTHON, test ${python_found} = "yes")
-
---
-1.8.4.2
-
diff --git a/recipes-security/libcap-ng/libcap-ng_0.7.7.bb
b/recipes-security/libcap-ng/libcap-ng_0.7.7.bb
deleted file mode 100644
index 5c5cd3d..000
--- a/recipes-security/libcap-ng/libcap-ng_0.7.7.bb
+++ /dev/null
@@ -1,40 +0,0 @@
-SUMMARY = "An alternate posix capabilities library"
-DESCRIPTION = "The libcap-ng library is intended to make programming \
-with POSIX capabilities much easier than the traditional libcap library."
-HOMEPAGE = "http://freecode.com/projects/libcap-ng";
-SECTION = "base"
-LICENSE = "GPLv2+ & LGPLv2.1+"
-LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
- file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06"
-
-SRC_URI = "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \
- file://python.patch \
- "
-
-inherit lib_package autotools pythonnative
-
-SRC_URI[md5sum] = "3d7d126b29e2869a0257c17c8b0d9b2e"
-SRC_URI[sha256sum] =
"615549ce39b333f6b78baee0c0b4ef18bc726c6bf1cca123dfd89dd963f6d06b"
-
-DEPENDS += "swig-native python"
-
-EXTRA_OECONF += "--without-python3"
-
-EXTRA_OEMAKE += "PYLIBVER='python${PYTHON_BASEVERSION}'
PYINC='${STAGING_INCDIR}/${PYLIBVER}'"
-
-PACKAGES += "${PN}-python"
-
-FILES_${PN}-dbg += "${libdir}/python${PYTHON_BASEVERSION}/*/.debug"
-FILES_${PN}-python = "${libdir}/python${PYTHON_BASEVERSION}"
-
-BBCLASSEXTEND = "native"
-
-do_install_append() {
- # Moving libcap-ng to base_libdir
- if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then
- mkdir -p ${D}/${base_libdir}/
- mv -f ${D}${libdir}/libcap-ng.so.* ${D}${base_libdir}/
- relpath=${@os.path.relpath("${base_libdir}", "${libdir}")}
- ln -sf ${relpath}/libcap-ng.so.0.0.0 ${D}${libdir}/libcap-ng.so
- fi
-}
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/2][meta-selinux] swig: remove package
From: Wenzong Fan
swig 3.0.6 has been added to oe-croe:
66923c6776da13bd4513a73c3f7c5e60d74eb0f3
No change need to port.
Signed-off-by: Wenzong Fan
---
recipes-devtools/swig/swig.inc | 59 --
...lf-exe-for-swig-swiglib-on-non-Win32-plat.patch | 69 --
...nfigure-use-pkg-config-for-pcre-detection.patch | 65
recipes-devtools/swig/swig_2.0.10.bb | 11
4 files changed, 204 deletions(-)
delete mode 100644 recipes-devtools/swig/swig.inc
delete mode 100644
recipes-devtools/swig/swig/0001-Use-proc-self-exe-for-swig-swiglib-on-non-Win32-plat.patch
delete mode 100644
recipes-devtools/swig/swig/0001-configure-use-pkg-config-for-pcre-detection.patch
delete mode 100644 recipes-devtools/swig/swig_2.0.10.bb
diff --git a/recipes-devtools/swig/swig.inc b/recipes-devtools/swig/swig.inc
deleted file mode 100644
index 74ce506..000
--- a/recipes-devtools/swig/swig.inc
+++ /dev/null
@@ -1,59 +0,0 @@
-DESCRIPTION = "SWIG - Simplified Wrapper and Interface Generator"
-HOMEPAGE = "http://swig.sourceforge.net/";
-LICENSE = "BSD & GPLv3"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=e7807a6282784a7dde4c846626b08fc6 \
-file://LICENSE-GPL;md5=d32239bcb673463ab874e80d47fae504 \
-
file://LICENSE-UNIVERSITIES;md5=8ce9dcc8f7c994de4a408b205c72ba08"
-
-SECTION = "devel"
-INC_PR = "r3"
-
-DEPENDS = "libpcre python"
-
-SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${PV}.tar.gz"
-
-inherit autotools pythonnative
-
-EXTRA_OECONF = " \
---with-python=${PYTHON} \
---without-allegrocl \
---without-android \
---without-boost \
---without-chicken \
---without-clisp \
---without-csharp \
---without-d \
---without-gcj \
---without-go \
---without-guile \
---without-java \
---without-lua \
---without-mzscheme \
---without-ocaml \
---without-octave \
---without-perl5 \
---without-pike \
---without-php \
---without-python3 \
---without-r \
---without-ruby \
---without-tcl \
-"
-
-BBCLASSEXTEND = "native nativesdk"
-
-do_configure() {
-install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess
${S}/Tools/config
-install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub
${S}/Tools/config
-install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess ${S}
-install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub ${S}
-oe_runconf
-}
-
-def swiglib_relpath(d):
-swiglib = d.getVar('datadir', True) + "/" + d.getVar('BPN', True) + "/" +
d.getVar('PV', True)
-return os.path.relpath(swiglib, d.getVar('bindir', True))
-
-do_install_append_class-native() {
- create_wrapper ${D}${bindir}/swig SWIG_LIB='`dirname
$''realpath`'/${@swiglib_relpath(d)}
-}
diff --git
a/recipes-devtools/swig/swig/0001-Use-proc-self-exe-for-swig-swiglib-on-non-Win32-plat.patch
b/recipes-devtools/swig/swig/0001-Use-proc-self-exe-for-swig-swiglib-on-non-Win32-plat.patch
deleted file mode 100644
index 81df3e2..000
---
a/recipes-devtools/swig/swig/0001-Use-proc-self-exe-for-swig-swiglib-on-non-Win32-plat.patch
+++ /dev/null
@@ -1,69 +0,0 @@
-From a4a0440a644c6c5e5da096efe3cf05ba309a284f Mon Sep 17 00:00:00 2001
-From: "NODA, Kai"
-Date: Sun, 22 Apr 2012 17:01:02 +0900
-Subject: [PATCH] Use /proc/self/exe for "swig -swiglib" on non-Win32
- platforms.
-
-If it wasn't found, then fall back to a fixed string just as before.
-
-Upstream-Status: Submitted
-http://sourceforge.net/mailarchive/message.php?msg_id=29179733
-
- Source/Modules/main.cxx | 24 ++--
- 1 file changed, 22 insertions(+), 2 deletions(-)
-
-diff --git a/Source/Modules/main.cxx b/Source/Modules/main.cxx
-index d2f5d3b..cbb0a12 100644
a/Source/Modules/main.cxx
-+++ b/Source/Modules/main.cxx
-@@ -26,6 +26,11 @@ char cvsroot_main_cxx[] = "$Id$";
- #include "cparse.h"
- #include
- #include// for INT_MAX
-+#ifndef _WIN32
-+#include
-+#include// for readlink
-+#include // for stat
-+#endif
-
- // Global variables
-
-@@ -902,9 +907,9 @@ int SWIG_main(int argc, char *argv[], Language *l) {
-
- // Check for SWIG_LIB environment variable
- if ((c = getenv("SWIG_LIB")) == (char *) 0) {
-+char *p;
- #if defined(_WIN32)
- char buf[MAX_PATH];
--char *p;
- if (!(GetModuleFileName(0, buf, MAX_PATH) == 0 || (p = strrchr(buf,
'\\')) == 0)) {
- *(p + 1) = '\0';
- SwigLib = NewStringf("%sLib", buf); // Native windows installation path
-@@ -914,7 +919,22 @@ int SWIG_main(int argc, char *argv[], Language *l) {
- if (Len(SWIG_LIB_WIN_UNIX) > 0)
- SwigLibWinUnix = NewString(SWIG_LIB_WIN_UNIX); // Unix installation
path using a drive letter (for msys/mingw)
- #else
--SwigLib = NewString(SWIG_LIB);
-+char buf[PATH_MAX];
-+if (0 < ::readlink("/proc/self/exe", buf, sizeof(buf)) &&
-+(p = ::strstr(buf, "/bin/swig"))) {
-+
