We are using AEM version 6.5.9
and our js processor config was
min:gcc;languageIn=ECMASCRIPT_2018;obfuscate=true
It works for normal cases but in case we have any optional chaining(e.g. adventurer.dog?.name) then it does not work
You can refer to this link for Online Compiler
In this online compiler if the language is ECMASCRIPT_2020 then it is able to compile else for the lower versions it does not.
The list of allowed language versions is from GitHub Link
So similarly in AEM we changed the js processor config to
min:gcc;languageIn=ECMASCRIPT_2020;obfuscate=true
But then also minification does not work.
My questions are:
Does AEM not support ECMASCRIPT_2020?
Is there any way we can update the gcc version being used by AEM?
Related
I downloaded the latest source code of Opensplice DDS from https://github.com/ADLINK-IST/opensplice and tried to build it by following its instructions (source setenv, source ./configure, then make ..) in my Cygwin 64 bit.
The build (make command) appeared to be completed, but a number of modules such as dcpsisocpp2, durability, spliced didn't get built (I can't find dcpsisocpp2.dll, etc).
I wonder if anyone who is familar with Opensplice's makefile system can direct me to solve the problem.
You should identify you are going to use community or enterprise version.
It seems the community version doesn't have spliced and durability services. Also, dcpsisocpp2 use C++03 which is a very old C++ standard, that when you use C++11 or C++14 writing your application, you might get some warning or error and spend lots of time fixing compile problems.
Try to use dcpssacpp which follows the C++11 standard.
Given a GLIBCXX version of the stdc++ library (example GLIBCXX_3.4.17) given this version, where would one find documentation which specifies what features have been implemented?
Further is there a way to which given the SO NAME version will provide the this same document.
I am working on an embedded system which has an existing version of libstdc++; unfortunately the supplied cross compiler (g++) is at a greater version than what the stdc++ library on the target supports. Upgrading the stdc++ library on the target is not an option. Before I write a lot of code, to only find that it does not run on the target; I would like to know beforehand what is and is not supported.
I have found the GNU Documentation to be useful; however, I am hoping there is a document in which one can get what has been implemented given the symbol version and/or the SO NAME and I just have somehow missed it.
Thanks for any help in advance
given this version, where would one find documentation which specifies what features have been implemented?
You can map a GLIBCXX_A.B.C symbol version to a GCC release by checking
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
N.B. that won't be precise, because e.g. GCC 5.1 and GCC 5.2 both use GLIBCXX_3.4.21 in the shared library. To tell them apart check the __GLIBCXX__ macro defined by the libstdc++ headers, also documented on that page.
The manuals for libstdc++ releases are at
gcc.gnu.org/onlinedocs/gcc-[X.Y.Z]/libstdc++/manual/
e.g.
https://gcc.gnu.org/onlinedocs/gcc-5.3.0/libstdc++/manual/
Within that manual is a status table showing the implementation status for each standard, the table for C++11 support in GCC 5.3.0 is at
https://gcc.gnu.org/onlinedocs/gcc-5.3.0/libstdc++/manual/manual/status.html#status.iso.2011
Before I write a lot of code, to only find that it does not run on the target; I would like to know beforehand what is and is not supported.
It's not enough to simply avoid using features that aren't supported by the library on the target system. If you link with the cross-compiler then it will depend on the libstdc++.so from that cross-compiler, and will fail to run on the target system if it only has an older libstdc++.so
Upgrading the stdc++ library on the target is not an option.
Then you either need to link statically (creating large executables) or downgrade your cross-compiler to match the target. Or at least force it to use the headers and dynamic library from the same version as found on the target (by overriding the header and library search paths to point to copies of the older files), although that might not work, as the newer g++ might not be able to compile the older headers if they contain some invalid C++ that the older g++ didn't diagnose.
Assume I have a plugin and I load it using the gcc -fplugin=foo.so...
Is there any preprocessor symbol or macro that gets defined that I can use to conditionally compile out language features that plugin requires.
Of course I can provide that macro on the command line, e.g -Dplugin_foo_loaded.
But it would be better if such macros were generated by the act of loading the plugin.
What is the answer?
Currently (GCC 4.9) you cannot do that, since there is no plugin hooks related to the preprocessor.
I guess that the simplest way would be to pass a -DMYPLUGIN. Or define some builtin in your plugin.
PS. If you are looking for some tutorial material about GCC plugins consider also MELT and some documentation there (e.g. slides on GCC plugins thru the MELT example; Linux Foundation, march 2014)
I'm using firebreath to develop a browser plugin in windows xp using visual studio 2010. The plugin uses boost signals, filesystem and system, libcurl libraries.
The plugin builds successfully but gives error while registering it using regsvr32:
LoadLibrary("np<plugin name>.dll") failed. The specified procedure could not be found.
After checking for a while, I found that if I remove the boost signals module, the plugin gets registered. I checked the plugin dll in dependency walker but there were no missing dlls. Though it showed module warning in ADVAPI32.DLL and MPR.DLL. Can anyone help me to solve this problem because I can't remove signals module from my project?
As discussed on the FireBreath mailing list, this could be something that firebreath isn't doing correctly when including its subset of boost. I would recommend trying to build and install boost yourself and then use the external boost flags on the prep script.
You can find the flags you need and others for prep scripts on the Prep Scripts page on the firebreath website.
At the very least you'll need to use "-D WITH_SYSTEM_BOOST=1"; you might need some of the other ones too.
-D BOOST_ROOT="/path/to/boost" - set to path to your Boost installation
-D Boost_ADDITIONAL_VERSIONS="<versions>" - set specific Boost version (e.g. "1.43;1.43.0")
-D Boost_USE_STATIC_LIBS=on
-D Boost_USE_STATIC_RUNTIME=on should be used in windows to force linking to the boost libraries built with /MT(d).
I am currently implementing a simple tcp/ip server using an Atmel AT91SAM9260 evaluation board (ARM based micro-controller with several peripherals).
Some examples, given by Atmel include a uIP based web server but uIP cannot handle the throughput needed.
I found the same example based on version 1.1.1 (or slightly above) that was serving me just enough.
Recently I began to have problems with the stack and I couldn't find a port to the AT91SAM9260 with a newer version of lwIP. To build the project, I am using Eclipse+Yagarto+gcc as a development stack.
After just replacing the source code of the latest version 1.4.0 (available at http://download.savannah.gnu.org/releases/lwip/) into my project and attempting to fix all compile errors, I gave up.
The structure of the source code is very similar but apparently there's too many tweaks to be made.
Is there a specific guide on adapting the original source code to my stack? Wasn't the C++ code supposed to just compile on my stack?
At the wiki of LwIP http://lwip.wikia.com/wiki/Projects_that_use_lwIP I do see a reference to contributed ports of LwIP 1.3.0. That may be a starting point, at least for the ethernetif.c file.
To try and answer the second question: The C (not C++) is supposed to compile, but one still has to (at least):
setup lwipopts.h to determine how LwIP is to be used
provide ethernetif.h/ethernetif.c to tie your hardware to LwIP
setup sys_arch.h/sys_arch.c