how to remove vendor name from crosstool-ng toolchain name - linux

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}"

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.

What does geeko#buildhost signify in linux version?

On a linux server when checking the Linux version I see the following "geeko#buildhost"
Version: Linux version 4.12.14-95.54-default (geeko#buildhost) (gcc version 4.8.5 (SUSE Linux) ) #1 SMP Thu Jun 4 12:49:28 UTC 2020 (892ef1f)
What does this signify? does it have something to do with who built the os packages?
It is simply an identifier showing the user and host names where the kernel is compiled. The former is the result of executing whoami and the latter is the result of running uname -n. You can see how it is put together in init/version.c:
const char linux_banner[] =
"Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "#"
LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n";
The variables are set by scripts/mkcompile_h:
if test -z "$KBUILD_BUILD_USER"; then
LINUX_COMPILE_BY=$(whoami | sed 's/\\/\\\\/')
else
LINUX_COMPILE_BY=$KBUILD_BUILD_USER
fi
if test -z "$KBUILD_BUILD_HOST"; then
LINUX_COMPILE_HOST=`uname -n`
else
LINUX_COMPILE_HOST=$KBUILD_BUILD_HOST
fi

ERROR: Patch can't be applied/reverted successfully

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.

What is the maximum size of a Linux environment variable value?

Is there a limit to the amount of data that can be stored in an environment variable on Linux, and if so: what is it?
For Windows, I've found following KB article which summarizes to:
Windows XP or later: 8191 characters
Windows 2000/NT 4.0: 2047 characters
I don't think there is a per-environment variable limit on Linux. The total size of all the environment variables put together is limited at execve() time. See "Limits on size of arguments and environment" here for more information.
A process may use setenv() or putenv() to grow the environment beyond the initial space allocated by exec.
Here's a quick and dirty program that creates a 256 MB environment variable.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
int main(void)
{
size_t size = 1 << 28; /* 256 MB */
char *var;
var = malloc(size);
if (var == NULL) {
perror("malloc");
return 1;
}
memset(var, 'X', size);
var[size - 1] = '\0';
var[0] = 'A';
var[1] = '=';
if (putenv(var) != 0) {
perror("putenv");
return 1;
}
/* Demonstrate E2BIG failure explained by paxdiablo */
execl("/bin/true", "true", (char *)NULL);
perror("execl");
printf("A=%s\n", getenv("A"));
return 0;
}
Well, it's at least 4M on my box. At that point, I got bored and wandered off. Hopefully the terminal output will be finished before I'm back at work on Monday :-)
export b1=A
export b2=$b1$b1
export b4=$b2$b2
export b8=$b4$b4
export b16=$b8$b8
export b32=$b16$b16
export b64=$b32$b32
export b128=$b64$b64
export b256=$b128$b128
export b512=$b256$b256
export b1k=$b512$b512
export b2k=$b1k$b1k
export b4k=$b2k$b2k
export b8k=$b4k$b4k
export b16k=$b8k$b8k
export b32k=$b16k$b16k
export b64k=$b32k$b32k
export b128k=$b64k$b64k
export b256k=$b128k$b128k
export b512k=$b256k$b256k
export b1m=$b512k$b512k
export b2m=$b1m$b1m
export b4m=$b2m$b2m
echo $b4m
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
: : : : : : : : : : : :
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
If you're worried that 4M may not be enough for your environment variable, you may want to rethink how you're doing things.
Perhaps it would be a better idea to put the information into a file and then use an environment variable to reference that file. I've seen cases where, if the variable is of the form #/path/to/any/fspec, it gets the actual information from the file path/to/any/fspec. If it doesn't begin with #, it uses the value of the environment variable itself.
Interestingly enough, with all those variables set, every single command starts complaining that the argument list is too long so, even though it lets you set them, it may not be able to start programs after you've done it (since it has to pass the environment to those programs).
Here are two helpful commands:
getconf -a | grep ARG_MAX
true | xargs --show-limits
I did a quick test on my Linux box with the following snippet:
a="1"
while true
do
a=$a$a
echo "$(date) $(numfmt --to=iec-i --suffix=B --padding=7 ${#a})"
done
On my box (Gentoo 3.17.8-gentoo-r1) this results in (last lines of output):
Wed Jan 3 12:16:10 CET 2018 16MiB
Wed Jan 3 12:16:11 CET 2018 32MiB
Wed Jan 3 12:16:12 CET 2018 64MiB
Wed Jan 3 12:16:15 CET 2018 128MiB
Wed Jan 3 12:16:21 CET 2018 256MiB
Wed Jan 3 12:16:33 CET 2018 512MiB
xrealloc: cannot allocate 18446744071562068096 bytes
So: the limit is quite high!
Don't know exactly but a quick experiment shows that no error occurs e.g. with 64kB of value:
% perl -e 'print "#include <stdlib.h>\nint main() { return setenv(\"FOO\", \"", "x"x65536, "\", 1); }\n";'\
| gcc -x c -o envtest - && ./envtest && echo $?
0
I used this very quick and dirty php code (below), modifying it for different values, and found that it works for variable lengths up to 128k. After that, for whatever reason, it doesn't work; no exception is raised, no error is reported, but the value does not show up in the subshell.
Maybe this is a php-specific limit? Maybe there are php.ini settings that might affect it? Or maybe there's a limit on the size of vars that a subshell will inherit? Maybe there are relevant kernel or shell config settings..
Anyway, by default, in CentOS, the limit for setting a var in the environment via putenv in php seems to be about 128k.
<?php
$s = 'abcdefghijklmnop';
$s2 = "";
for ($i = 0; $i < 8100; $i++) $s2 .= $s;
$result = putenv('FOO='.$s2);
print shell_exec('echo \'FOO: \'${FOO}');
print "length of s2: ".strlen($s2)."\n";
print "result = $result\n";
?>
Version info -
[root#localhost scratch]# php --version
PHP 5.2.6 (cli) (built: Dec 2 2008 16:32:08)
<..snip..>
[root#localhost scratch]# uname -a
Linux localhost.localdomain 2.6.18-128.2.1.el5 #1 SMP Tue Jul 14 06:36:37 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
[root#localhost scratch]# cat /etc/redhat-release
CentOS release 5.3 (Final)
The command line (with all argument) plus the environment variable should be less then 128k.
In my case it was due to buffer was limited when accepting a variable input value with read command. Solution was to add -e
Before read accessToken
After read -e accessToken
Docs: http://linuxcommand.org/lc3_man_pages/readh.html

Resources