Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » Reg. GCC versions(gcc version file)
Reg. GCC versions [message #1806058] Wed, 01 May 2019 21:07 Go to next message
Mohan Raj Janardhan is currently offline Mohan Raj JanardhanFriend
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 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1063
Registered: January 2015
Senior Member
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 #1806082 is a reply to message #1806070] Thu, 02 May 2019 11:48 Go to previous messageGo to next message
Mohan Raj Janardhan is currently offline Mohan Raj JanardhanFriend
Messages: 32
Registered: October 2018
Member
Thanks Elemer,

1. Can you provide the link to README.linux
2. Also when downgrading, can you let me know how do we change the with--package as indicated in my above message.. though i change the version of GCC, is till see the configure with package pointing to the previous package. I will try with other alternatives.

Thanks
Mohan Raj
Re: Reg. GCC versions [message #1806087 is a reply to message #1806082] Thu, 02 May 2019 12:03 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1063
Registered: January 2015
Senior Member
Hi Mohan.


1.
The code is located in github at:
https://github.com/eclipse/titan.core

Releases are tagged and can be downloaded from:
https://github.com/eclipse/titan.core/releases

and here it is explained how a build from scratch can be done:

https://github.com/eclipse/titan.core/blob/master/README.linux

2. This requires Ubuntu etc. competence and it is not our place to advise regarding that.

However, let me remind you that in later Ubuntu versions the titan core can be installed directly:

sudo apt-get update
sudo apt-get install eclipse-titan

see
https://www.eclipse.org/forums/index.php/t/1086995/
(Eclipse Titan available in debian 9 and Ubuntu 17.04)

so that might be an easier path to take (although the Titan version thus installed may not be the latest)



Best regards
Elemer



Re: Reg. GCC versions [message #1806187 is a reply to message #1806087] Sun, 05 May 2019 14:30 Go to previous messageGo to next message
Anupam Rajanish is currently offline Anupam RajanishFriend
Messages: 3
Registered: May 2019
Junior Member
Hi Elmer,
I am new to TItan IDE. Currently i have Ubuntu 18.0.4.
I have installed the Titan TTCN3 Execution plugin for eclipse. And i was following the previous installation document until i read about the direct installation.
After having executed that in CLI, my question remains what should i now set as the Titan installation path in my eclipse?
Re: Reg. GCC versions [message #1806228 is a reply to message #1806087] Mon, 06 May 2019 14:21 Go to previous messageGo to next message
David Laurent is currently offline David LaurentFriend
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 #1806235 is a reply to message #1806058] Mon, 06 May 2019 16:15 Go to previous messageGo to next message
Harald Welte is currently offline Harald WelteFriend
Messages: 106
Registered: July 2017
Location: Berlin, Germany
Senior Member

Regarding this context, please also see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879816 as well as https://github.com/eclipse/titan.core/commit/425a11165fa7b88ca36ca363fc714432e46822fb

As I and others have pointed out several times: There is no known requirement for requiring the exact same compiler version being used for all object files when linking.

There was *once* a known bug more than ten years ago with gcc-4.1.2. Modern TITAN versions requiring the exact compiler version match shouldn't be affected by one such bug more than a decade ago. Nobody should be using such ancient compilers (gcc 4.1.2) anymore.

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879816#82

I would argue that the exact compiler version check is causing more breakage these days than it is intended to prevent.
Re: Reg. GCC versions [message #1806241 is a reply to message #1806235] Mon, 06 May 2019 17:11 Go to previous messageGo to next message
Mohan Raj Janardhan is currently offline Mohan Raj JanardhanFriend
Messages: 32
Registered: October 2018
Member
Hi Elemer,

Thanks for the information. We understand that this issue has been re-occuring a lot. Is there a solution already for this? Or is there any way out for us?? We are dependent on your answer, as we could not find a way out for this issue.

Thanks
Mohan raj
Re: Reg. GCC versions [message #1806268 is a reply to message #1806241] Tue, 07 May 2019 09:05 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1063
Registered: January 2015
Senior Member
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 Go to previous messageGo to next message
Kristof Szabados is currently offline Kristof SzabadosFriend
Messages: 54
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 https://drive.google.com/open?id=1ae3Y_5UzK7m0BljmAR0lakyIEw5V-Zhl
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 40 times)
Re: Reg. GCC versions [message #1806397 is a reply to message #1806290] Wed, 08 May 2019 12:41 Go to previous messageGo to next message
David Laurent is currently offline David LaurentFriend
Messages: 68
Registered: September 2018
Member
Hi All,

Thx for your feedbacks.
We are downgrading our OS to gcc 7.3 in order to comply with TTCN compiler.
http://ftp.gnome.org/mirror/eclipse.org/titan/ttcn3-6.4.pl0-linux64-gcc7.3-ubuntu18.04.tgz

FYI, we are using this procedure: https://gcc.gnu.org/wiki/InstallingGCC
If you know a better one, please feel free to respond.

After reverting back OS gcc to 7.3.0 version, we had to cleanup other component dependent on gcc 7.4.0 and when we revert them back to 7.3 as well...other components complained....this is a major show stopper.

In short, we would welcome TTCN compiler version free as in this https://github.com/eclipse/titan.core/commit/425a11165fa7b88ca36ca363fc714432e46822fb

Regards - David

[Updated on: Wed, 08 May 2019 20:29]

Report message to a moderator

Re: Reg. GCC versions [message #1806442 is a reply to message #1806397] Thu, 09 May 2019 07:29 Go to previous messageGo to next message
Kristof Szabados is currently offline Kristof SzabadosFriend
Messages: 54
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 Go to previous messageGo to next message
David Laurent is currently offline David LaurentFriend
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 #1806581 is a reply to message #1806577] Fri, 10 May 2019 15:49 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1063
Registered: January 2015
Senior Member
Hi David,

what is the gcc version as displayed by "g++ -v" ?

BR
Elemer
Re: Reg. GCC versions [message #1806666 is a reply to message #1806581] Mon, 13 May 2019 13:01 Go to previous messageGo to next message
David Laurent is currently offline David LaurentFriend
Messages: 68
Registered: September 2018
Member
Hi Elemer,

I have also displayed this in my previous printout.

Regards - David

$ dpkg --list | grep -i g++
ii  g++                                   4:7.3.0-3ubuntu2                  amd64        GNU C++ compiler


[Updated on: Mon, 13 May 2019 13:12]

Report message to a moderator

Re: Reg. GCC versions [message #1806669 is a reply to message #1806666] Mon, 13 May 2019 14:20 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1063
Registered: January 2015
Senior Member
Hi David,

maybe you did, but that is not what I asked for.
I asked for the output of the command
g++ -v





Re: Reg. GCC versions [message #1806684 is a reply to message #1806669] Mon, 13 May 2019 20:25 Go to previous messageGo to next message
David Laurent is currently offline David LaurentFriend
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 #1806692 is a reply to message #1806684] Tue, 14 May 2019 06:32 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1063
Registered: January 2015
Senior Member
Hi David,

from this becomes obvious that gcc version 7.4.0 is visible to users, hence Titan as well.
This means that your installation of gcc 7.3.0 is incomplete or failed.

I hope this helps

Elemer


[Updated on: Tue, 14 May 2019 07:13]

Report message to a moderator

Re: Reg. GCC versions [message #1806860 is a reply to message #1806692] Thu, 16 May 2019 13:18 Go to previous messageGo to next message
David Laurent is currently offline David LaurentFriend
Messages: 68
Registered: September 2018
Member
Hi Elemer,

We have successfully built a TTCN binary for gcc 7.4 on Ubuntu 18.04.2
and will systemize the procedure for future version upgrade.

Regards - David
Re: Reg. GCC versions [message #1806863 is a reply to message #1806860] Thu, 16 May 2019 14:26 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1063
Registered: January 2015
Senior Member
Hi David,

great stuff.

Best regards
Elemer
Re: Reg. GCC versions [message #1806872 is a reply to message #1806863] Thu, 16 May 2019 19:57 Go to previous messageGo to next message
Mohan Raj Janardhan is currently offline Mohan Raj JanardhanFriend
Messages: 32
Registered: October 2018
Member
Hi Elemer,

Do we have to do anything for the executor plugin on top of this? As of now it is compiling with the new binary.

Thanks
Mohan Raj
Re: Reg. GCC versions [message #1806882 is a reply to message #1806872] Fri, 17 May 2019 06:45 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1063
Registered: January 2015
Senior Member
Hi Mohan,

no, the plug-ins should work fine.

BR

Elemer
Re: Reg. GCC versions [message #1807036 is a reply to message #1806882] Tue, 21 May 2019 14:32 Go to previous messageGo to next message
Mohan Raj Janardhan is currently offline Mohan Raj JanardhanFriend
Messages: 32
Registered: October 2018
Member
Thanke Elemer.

Also, we had to do an update on the ttcn3_start, for our case. That when we remote login and run the ttcn3_start on a server, it gave an error in the below area

if {[info exists env(TTCN3_DIR)]} {
set mctr $env(TTCN3_DIR)/bin/mctr_cli
} else {
puts "ttcn3_start: warning: TTCN3_DIR environment variable is not set"
set mctr /path/to/driectory/mctr_cli
}

We had to manually fill in the path to directory. What we found was, the script was running if we had to start it manually. But when we had to auotmate, via remote connected it wasn't getting the /path/to/dir for mctr_cli. This is just for your information.
Re: Reg. GCC versions [message #1807039 is a reply to message #1807036] Tue, 21 May 2019 15:49 Go to previous message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1063
Registered: January 2015
Senior Member
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

Previous Topic:TTCN3 Ethernet TCP Socket program
Next Topic:SSH login
Goto Forum:
  


Current Time: Wed Jul 08 05:23:30 GMT 2020

Powered by FUDForum. Page generated in 0.03476 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top