Home » Eclipse Projects » Eclipse Titan » Reg. GCC versions(gcc version file)
| Reg. GCC versions [message #1806058] |
Wed, 01 May 2019 21:07  |
 Mohan Raj Janardhan
Messages: 32
Registered: October 2018 |
Member |
|
|
Hi Elemer,
Everday our servers get kickstarted with new OS and suddenly yesterday, we found issues compiling our test cases, due to mismatch
In file included from /opt/TTCN3/include/TTCN3.hh:42:0,
from UsefulTtcn3Types.hh:19,
from UsefulTtcn3Types.cc:11:
/opt/TTCN3/include/cversion.h:7:2: error: #error The version of GCC does not match the expected version (GCC 7.3.0)
#error The version of GCC does not match the expected version (GCC 7.3.0)
^~~~~
then happen to find, our servers were showing gcc version as 7.4.
In the backup (which we load daily to run the executable) we install for the eclipse, we are picking up 7.3 from the below location:
http://ftp.gnome.org/mirror/eclipse.org/titan/ttcn3-6.4.pl0-linux64-gcc7.3-ubuntu18.04.tgz
I could not find the gcc7.4 in this location or any other location from google.
1. It would help if you can provide us the location to download gcc7.4.
2. Also i did the following, by doing an update-alternatives to change back to 7.3, but could not get it properly, because even after downgrading the version, if i do a gcc -v
i couldn't change the pkg-version to 7.3 it always shows 7.4 like below
root@r620-21D4FX1:/home/ts3# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.4.0-1ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04)
Is there a way to change the pkgversion? I get a g++ not found error after this.
root@r620-21D4FX1:~# dpkg --list | grep compiler
ii g++ 4:7.4.0-1ubuntu2.2 amd64 GNU C++ compiler
ii g++-7 7.4.0-1ubuntu1~18.04 amd64 GNU C++ compiler
ii gcc 4:7.4.0-1ubuntu2.2 amd64 GNU C compiler
ii gcc-7 7.4.0-1ubuntu1~18.04 amd64 GNU C compiler
ii gcc-7-multilib 7.4.0-1ubuntu1~18.04 amd64 GNU C compiler (multilib support)
ii libllvm7:amd64 1:7-3~ubuntu0.18.04.1 amd64 Modular compiler and toolchain technologies, runtime library
|
|
|
| Re: Reg. GCC versions [message #1806070 is a reply to message #1806058] |
Thu, 02 May 2019 08:16  |
|
Hi Mohan,
1. we only provide binaries for the gcc version that is current in the targeted OS at the moment of release.
Unfortunately we don't have resources to build binaries for any random combination of OS/C compiler/Titan version.
If the C/C++ compiler changes due OS upgrade, than you either have to fallback to the original version of it, or upgrade your Titan binaries by building them from the source code available in github,
see README.linux for details.
2. Installation of alternative C/C++ compiler versions is not a Titan specific issue, probably it's not us who are most entitled to answer this.
Please refer to the Ubuntu support literature.
(It appears to me though that you may have installed gcc but not g++, which is a different animal, as alternative)
Best regards
Elemer
|
|
| | | |
| Re: Reg. GCC versions [message #1806228 is a reply to message #1806087] |
Mon, 06 May 2019 14:21 |
David Laurent
Messages: 68
Registered: September 2018 |
Member |
|
|
Hi Elemer,
Thx....if we follow your advise and grab the latest build, would TTCN-3 gcc plugin be compatible with the latest ubuntu 18.04 gcc version 7.4 ?
https://github.com/eclipse/titan.core/releases
As of today, we have a deadlock on the mismatch version between TTCN-3 compiler and the gcc ubuntu 18 platform.
The Titan binary package, built on Ubuntu 18.04, stops at ttcn3-6.4.pl0-linux64-gcc7.3-ubuntu18.04.tgz:
http://ftp.gnome.org/mirror/eclipse.org/titan/
FYI, the latest gcc version is up to 9.1: https://gcc.gnu.org/
And applying update-alternatives to select gcc 7.3 did not help
Regards - David
$:/tmp# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.4.0-1ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04)
After applying these commands:
sudo apt-get update
sudo apt-get install eclipse-titan
$:/tmp# compiler -v
TTCN-3 and ASN.1 Compiler for the TTCN-3 Test Executor
Product number: CRL 113 200/6 R4A
Build date: Jun 12 2018 08:36:32
Compiled with: GCC 7.3.0
Using OpenSSL 1.1.0g 2 Nov 2017
$:/tmp# apt-cache policy eclipse-titan
eclipse-titan:
Installed: 6.3.1-1build1.2
Candidate: 6.3.1-1build1.2
Version table:
*** 6.3.1-1build1.2 500
500 http://us.archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages
100 /var/lib/dpkg/status
6.3.1-1build1 500
500 http://us.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
[Updated on: Mon, 06 May 2019 15:13] Report message to a moderator |
|
| | |
| Re: Reg. GCC versions [message #1806268 is a reply to message #1806241] |
Tue, 07 May 2019 09:05 |
|
Dear all,
technically Harald is right, however:
-the current verification creates a clear and unambiguous situation, where the gcc version is unique across the Titan binaries and the binaries generated with Titan.
The final executable contains both kinds of binaries, so we may end up in a situation where binaries compiled with two (or even more?) different versions of gcc-s (or gcc and clang mixed?) are linked together.
My main problem with this situation is that it creates a status that is very difficult to reproduce from troubleshooting point of view: probably no user will know which part was generated with which gcc.
Add to this the fact that the problems generated are potentially very confusing and difficult to debug. So I prefer to be very conservative to open this door as in my opinion it will create more problems than it solves.
The current solutions are fairy simple: either you build from scratch a Titan for exactly your environment , or you update your environment to match your Titan build.
With just a little discipline, we can avoid much bigger problems..
@David: Again, the requirement is that you use the same version of C++ compiler that has been used when building Titan should be used when using Titan to build binaries.
That is , if you have
ttcn3-6.4.pl0-linux64-gcc7.3-ubuntu18.04.tgz
than you need to install gcc 7.3 on your OS
(or build Titan with the version of gcc that already resides on your OS).
@Mohan: I don't agree with your formulation that this would be an "issue" that is "reoccurring". This is a built in safety mechanism that has to be respected.
Simply put, it's a feature, not a bug. :)
However , we will look into the possibility to relax this rule, maybe starting from the third digit, but don't take this as a promise, and even if we will do it, it will take
an amount of testing, hence time.
I hope this clarifies things somewhat
Best regards
Elemer
|
|
|
| Re: Reg. GCC versions [message #1806290 is a reply to message #1806268] |
Tue, 07 May 2019 12:27 |
Kristof Szabados
Messages: 60
Registered: July 2015 |
Member |
|
|
Hi everyone,
Just one more info for the background of this check.
It might happen that these checks are no longer needed, but we have had many-many issues in the past with such incompatibilities.
As far as I can remember we have started supporting gcc with the 2.95.3 version on both Solaris and Linux.
And so many Linux versions it is hard to even keep track of. Once for an internal presentation, several years ago, I counted 50+ platform (operating system + gcc combination) that we offered long term support for (TITAN should still be able to compile for each even now).
This of course came with so many "interesting" situations:
- people trying to link together objects built on solaris and Linux, or objects built with different gcc versions (the joy of central storages being available from different places).
- having their own "special" branches of gcc
- or simply just letting anyone change any option on their test systems ... and still expecting everything to work for everyone.
- we have encountered testers who were so good hackers, that they run some extra "scripts" on the generated binaries to make them faster ... and some testers who could not tell when the build has finished (CPU utilization dropping below 100% percent and getting back the prompt not being enough hints ;) )
- but from testing point of view the worst situation is when people are not in control of their testbeds. One morning the same login takes them to a new virtual machine with a slightly different gcc or operating system (that is not visible), but all of their files from yesterday are still available from a central storage and tests start to be flaky. This can very well happen if the system admin accidentally upgardes even the testbeds (and even without previous notice)
Yet the most frustrating one was an issue with a particular version of gcc (or actually two versions)
The user reported, that everything works fine, but the logmerge utility drops about every 3rd character from the merged output.
It took us weeks until we figured out that the problem was coming from a mismatch in gcc versions.
TITAN was built on a SLES with gcc version 4.1.2 20070115 (SUSE Linux) ... the user has a SLES with gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)
I hope this can be seen on this image 
But the biggest problem was, that while we could not figure out what the issue was ... the users reporting this issue could also not "really" go on with their work.
Meaning, that they were developing their tests, and executing them ... but as the logs were not correct, had to spend an enormous part of the productive time with either guessing which letters might be missing, or trying to pair up log events from dozens of log files.
So even from just pure technical point of views, having such strict checks has several benefits for us and our users (or had in the past):
- We have limited resources, so having the exact same "platform" both on our site and at a user's site makes support just sooo much easier.
Instead of figuring out what extra patches might be applied to what parts of the system (etc...) we can simply identify the platform and start working on fixing the actual issue.
- In my experience many of our users (atleast internal ones) are thinking in testing and TTCN terms ... they are not really interested in operating system and gcc versions.
As such they are most of the time not that much willing (or able) to do much with stack dumps, linker errors or even gcc/clang warnings/errors.
They just want us to detect any issue, that might compromise their testscenarios as early as possible (why even try to execute a test if its results might not be reliable), and ideally provide a high-level actionable error message (this is not the expected gcc version)
---
That said if gcc/clang is more reliable now, this should be relaxed ... that will need some heavy investigation to make sure we can still provide a safe environment for our users like that.
Attachment: WTF_SUSE.png
(Size: 46.90KB, Downloaded 118 times)
|
|
| |
| Re: Reg. GCC versions [message #1806442 is a reply to message #1806397] |
Thu, 09 May 2019 07:29 |
Kristof Szabados
Messages: 60
Registered: July 2015 |
Member |
|
|
Hi,
Please note, that there are some subtle differences in testing compared to general software development.
While in general software development we always strive to use the newest, shiniest, stuff that gives us just 1 CPU clock more speed ... that might not really be the best idea in testing.
From what I gathered from industrial testers, their best practice involves fixing the environment used for testing for larger durations, and not allow any messing with that, unless absolutely necessary.
The ground idea for this, is that in essence when you are developing a "production software" and a "testing system", you have two complex systems that move at the same time ... and that creates problems.
One of which is simply just telling, in case of a fail result, if the problem is in the product or somewhere in the test, or somewhere in the environment.
- if the "test" and "production" code is written by the same person, these should be aligned ... but the test will not be able to reveal if that person misunderstood something (since he implemented both side the same way)
- if the "test" and "production" code is written by different people, maybe at different times ... both can be wrong, even at the same time. (if we would know how to build perfect software, we would not need testing ... but as we do not know how to build perfect software we also have to accept that the software we built for testing might also not be perfect)
- and of course there is also the environment, with all its who-knows-how-reliable components (hardware can fail, software can fail, networks can fail, stuff just might be scheduled differently in different runs, some background synch operation might startup and cause delays, etc... )
- + there is also the theoretical problem of comparing yesterday's results to today's results, knowing that we changed the measuring device in between.
One best practice I have seen to be used and saving lots of people from headaches, is to fix down some parts of the system, so that you only need to concentrate on one moving part at a time.
- It is usually a good idea to fix the setup of your testbed for durations of time. This way if you receive a fail report for a test, you can be pretty sure that it is not a problem with the test (if you have been executing the same test in the same environment without issues for weeks/months). This can be done directly with machines, with virtual machines you start up in the exact same state every time, etc...
- If you have the means, it is also a good practice to separate your environment from the rest of the world. That would fix problems with outside forces influencing your testing, from malware being installed, accidental heavy traffic directed your way, otherwise harmless automatic refreshing of your systems, etc... .
- Also when you wish to upgrade you testing setup, it is a good practice to choose a period of time when the product your testing is not changing (or not expected to change that much), to make sure that if any problems appear it is because of the testing setup being changed and not something else.
When this is physically not possible, or otherwise unrealistic (for example both "test" and "production" software is developed every minute of the day, or you would have to stop a 100+ organization working on tests), it might be a good practice to set up a parallel test environment which receives the same "product" testing request, but uses the newly built "test" setup. This will also needs to have the "means" for it, but if you have 24/7 development by hundreds of people on both the "product" and "test" software, allocating some extra hardware and dedicating a team a people to this effort, for its duration, is not that much of an extra cost.
Disclaimer: Please note that, I might be biased towards large-scale systems, coming from my work environment (and testing related meetup experiences) where we have some products so large, that even their tests in TTCN-3 are millions of lines of code large, and even the tests are developed by 26 teams in parallel. Also I have done my PhD. researching such large-scale test systems.
In smaller environments these best practices might be an overkill.
|
|
|
| Re: Reg. GCC versions [message #1806577 is a reply to message #1806442] |
Fri, 10 May 2019 15:16 |
David Laurent
Messages: 68
Registered: September 2018 |
Member |
|
|
Hi Elemer,
Based on your previous reply:
@David: Again, the requirement is that you use the same version of C++ compiler that has been used when building Titan should be used when using Titan to build binaries.
That is , if you have
ttcn3-6.4.pl0-linux64-gcc7.3-ubuntu18.04.tgz
than you need to install gcc 7.3 on your OS
(or build Titan with the version of gcc that already resides on your OS).
- We revert back gcc, g++ and other component to 7.3.0 with no progress as it's still complaining on TTCN Compiler incompatibility
- We are now looking into changing the version validation in /opt/TTCN3/bin/titanver
- If we get the same result...we'll downgrade to ubuntu 16.04 alongside with the compatible Titan Compiler.
Regards - David
Creating dependency file for MobileDomainDefinitions.cc
In file included from /opt/TTCN3/include/TTCN3.hh:42:0,
from MobileDomainDefinitions.hh:19,
from MobileDomainDefinitions.cc:11:
/opt/TTCN3/include/cversion.h:7:2: error: #error The version of GCC does not match the expected version (GCC 7.3.0)
#error The version of GCC does not match the expected version (GCC 7.3.0)
$ cat /proc/version
Linux version 4.15.0-48-generic (buildd@lgw01-amd64-036) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3))
$ dpkg --list | grep -i gcc
ii gcc 4:7.3.0-1ubuntu2.2 amd64 GNU C compiler
ii gcc-7 7.3.0-16ubuntu3 amd64 GNU C compiler
ii gcc-7-base:amd64 7.3.0-16ubuntu3 amd64 GCC, the GNU Compiler Collection (base package)
ii gcc-8-base:amd64 8.3.0-6ubuntu1~18.04 amd64 GCC, the GNU Compiler Collection (base package)
ii libcc1-0:amd64 8.3.0-6ubuntu1~18.04 amd64 GCC cc1 plugin for GDB
ii libgcc-7-dev:amd64 7.3.0-16ubuntu3 amd64 GCC support library (development files)
ii libgcc1:amd64 1:8.3.0-6ubuntu1~18.04 amd64 GCC support library
ii libgomp1:amd64 8.3.0-6ubuntu1~18.04 amd64 GCC OpenMP (GOMP) support library
ii libquadmath0:amd64 8.3.0-6ubuntu1~18.04 amd64 GCC Quad-Precision Math Library
$ dpkg --list | grep -i g++
ii g++ 4:7.3.0-3ubuntu2 amd64 GNU C++ compiler
[Updated on: Fri, 10 May 2019 15:39] Report message to a moderator |
|
| | | |
| Re: Reg. GCC versions [message #1806684 is a reply to message #1806669] |
Mon, 13 May 2019 20:25 |
David Laurent
Messages: 68
Registered: September 2018 |
Member |
|
|
Hi Elemer,
Here is the printout.
Regards - David
~# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.4.0-1ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04)
[Updated on: Mon, 13 May 2019 20:28] Report message to a moderator |
|
| | | | | | |
| Re: Reg. GCC versions [message #1807039 is a reply to message #1807036] |
Tue, 21 May 2019 15:49 |
|
Hi Mohan,
this might not be necessary;
if you set the environment variables as described in
https://github.com/eclipse/titan.core/blob/master/README.linux
5. Set environment variables
setenv TTCN3_DIR /home/<user id>/titan.core/Install
setenv PATH /home/<userid>/titan.core/Install/bin/:${PATH}
setenv LD_LIBRARY_PATH /home/<userid>/titan.core/Install/lib:${LD_LIBRARY_PATH}
for csh
or
export TTCN3_DIR=/home/<user id>/titan.core/Install
export PATH=/home/<userid>/titan.core/Install/bin/:${PATH}
export LD_LIBRARY_PATH=/home/<userid>/titan.core/Install/lib:${LD_LIBRARY_PATH}
for bash
and then add these to the appropriate login script,
then all Titan binaries will become visible.
Best regards
Elemer
|
|
|
Goto Forum:
Current Time: Fri Apr 19 11:38:13 GMT 2024
Powered by FUDForum. Page generated in 0.08661 seconds |
] 
Search
Help
Register
Login
Home
