The place I work uses Google Protocol Buffers for formatting messages that get sent between systems of different architectures. In the case of interest to me, that is between a big Java program running on Linux systems and the code I maintain on J-series and L-series NonStop systems.
Many years ago, I ported the then-current version of Google Protocol Buffers to the NonStop system, and it took me a LOT of time to do so. I don't recall exactly how long, but it was at least several weeks, and might have been over a month;. I haveused that old version ever since then because of the large effort I expected it would take to port newer versions. But my managers want to move up to the current version of Google Protocol Buffers, so I'll need to dive in and port the current version.
What I'm hoping to get in response to this post is advice about how to go about doing a port of an open source package to the NonStop environment, both J-series and L-series. I recall the general approach of running the configure step, the make step,and the install step that most open source packages use. Google Protocol Buffers did use that approach (I assume the current version still follows that approach). I don't recall the details of the problems I had in the prior port, but I recall having
What are things that might not be obvious to someone not very experienced in porting stuff to the NonStop system? Don't assume anything is so obvious that it doesn't need to be mentioned. I would much rather have you tell me things I already know thannot to learn about something I don't know. Also, what things are there that people sometimes do when trying to port software that might seem like the normal thing to do, but actually should be avoided because they lead to problems?
On Thursday, June 30, 2022 at 3:03:26 p.m. UTC-4, rkd...@gmail.com wrote:series and L-series NonStop systems.
The place I work uses Google Protocol Buffers for formatting messages that get sent between systems of different architectures. In the case of interest to me, that is between a big Java program running on Linux systems and the code I maintain on J-
used that old version ever since then because of the large effort I expected it would take to port newer versions. But my managers want to move up to the current version of Google Protocol Buffers, so I'll need to dive in and port the current version.
Many years ago, I ported the then-current version of Google Protocol Buffers to the NonStop system, and it took me a LOT of time to do so. I don't recall exactly how long, but it was at least several weeks, and might have been over a month;. I have
and the install step that most open source packages use. Google Protocol Buffers did use that approach (I assume the current version still follows that approach). I don't recall the details of the problems I had in the prior port, but I recall having
What I'm hoping to get in response to this post is advice about how to go about doing a port of an open source package to the NonStop environment, both J-series and L-series. I recall the general approach of running the configure step, the make step,
not to learn about something I don't know. Also, what things are there that people sometimes do when trying to port software that might seem like the normal thing to do, but actually should be avoided because they lead to problems?
What are things that might not be obvious to someone not very experienced in porting stuff to the NonStop system? Don't assume anything is so obvious that it doesn't need to be mentioned. I would much rather have you tell me things I already know than
What language is the package? There are different issues with different languages. With C, you will need to understand the dependencies. If the project absolutely depends on gcc, which many do, you are not going to be able to port it withoutsignificant effort. Understanding what compilers are involved is really important. It also depends on whether you are going a "light" vs. "deep" port. If you are just trying to get it to run, that is one thing, but run efficiently is another.
Good luck,
Randall
On Thursday, June 30, 2022 at 3:03:26 p.m. UTC-4, rkd...@gmail.com wrote:series and L-series NonStop systems.
The place I work uses Google Protocol Buffers for formatting messages that get sent between systems of different architectures. In the case of interest to me, that is between a big Java program running on Linux systems and the code I maintain on J-
used that old version ever since then because of the large effort I expected it would take to port newer versions. But my managers want to move up to the current version of Google Protocol Buffers, so I'll need to dive in and port the current version.Many years ago, I ported the then-current version of Google Protocol Buffers to the NonStop system, and it took me a LOT of time to do so. I don't recall exactly how long, but it was at least several weeks, and might have been over a month;. I have
and the install step that most open source packages use. Google Protocol Buffers did use that approach (I assume the current version still follows that approach). I don't recall the details of the problems I had in the prior port, but I recall havingWhat I'm hoping to get in response to this post is advice about how to go about doing a port of an open source package to the NonStop environment, both J-series and L-series. I recall the general approach of running the configure step, the make step,
than not to learn about something I don't know. Also, what things are there that people sometimes do when trying to port software that might seem like the normal thing to do, but actually should be avoided because they lead to problems?What are things that might not be obvious to someone not very experienced in porting stuff to the NonStop system? Don't assume anything is so obvious that it doesn't need to be mentioned. I would much rather have you tell me things I already know
What language is the package? There are different issues with different languages. With C, you will need to understand the dependencies. If the project absolutely depends on gcc, which many do, you are not going to be able to port it withoutsignificant effort. Understanding what compilers are involved is really important. It also depends on whether you are going a "light" vs. "deep" port. If you are just trying to get it to run, that is one thing, but run efficiently is another.
Good luck,
Randall
On 6/30/2022 4:05 PM, Randall wrote:series and L-series NonStop systems.
On Thursday, June 30, 2022 at 3:03:26 p.m. UTC-4, rkd...@gmail.com wrote:
The place I work uses Google Protocol Buffers for formatting messages that get sent between systems of different architectures. In the case of interest to me, that is between a big Java program running on Linux systems and the code I maintain on J-
used that old version ever since then because of the large effort I expected it would take to port newer versions. But my managers want to move up to the current version of Google Protocol Buffers, so I'll need to dive in and port the current version.
Many years ago, I ported the then-current version of Google Protocol Buffers to the NonStop system, and it took me a LOT of time to do so. I don't recall exactly how long, but it was at least several weeks, and might have been over a month;. I have
and the install step that most open source packages use. Google Protocol Buffers did use that approach (I assume the current version still follows that approach). I don't recall the details of the problems I had in the prior port, but I recall having
What I'm hoping to get in response to this post is advice about how to go about doing a port of an open source package to the NonStop environment, both J-series and L-series. I recall the general approach of running the configure step, the make step,
than not to learn about something I don't know. Also, what things are there that people sometimes do when trying to port software that might seem like the normal thing to do, but actually should be avoided because they lead to problems?
What are things that might not be obvious to someone not very experienced in porting stuff to the NonStop system? Don't assume anything is so obvious that it doesn't need to be mentioned. I would much rather have you tell me things I already know
significant effort. Understanding what compilers are involved is really important. It also depends on whether you are going a "light" vs. "deep" port. If you are just trying to get it to run, that is one thing, but run efficiently is another.What language is the package? There are different issues with different languages. With C, you will need to understand the dependencies. If the project absolutely depends on gcc, which many do, you are not going to be able to port it without
Good luck,In addition to what Randall said, HPE does have an OSS porting guide available on the documentation site.
Randall
The Google Protocol Buffers package (GPB) is entirely C++. Unless my memory is playing tricks on me, GPB does not depend on any other open source libraries to run, but it does use a number of open source programs in the course of building GPB.
On 7/1/2022 12:11 AM, Keith Dick wrote:
The Google Protocol Buffers package (GPB) is entirely C++. Unless my memory is playing tricks on me, GPB does not depend on any other open source libraries to run, but it does use a number of open source programs in the course of building GPB.
One note... If it's C++11, you can only build for an L-RVU, not for J.
If it's C++14 or later, you're completely out of luck.
On Friday, July 1, 2022 at 11:41:49 a.m. UTC-4, red floyd wrote:
On 7/1/2022 12:11 AM, Keith Dick wrote:
The Google Protocol Buffers package (GPB) is entirely C++. Unless my memory is playing tricks on me, GPB does not depend on any other open source libraries to run, but it does use a number of open source programs in the course of building GPB.
One note... If it's C++11, you can only build for an L-RVU, not for J.Big caution that if g++ is required, you are going to have to make a lot of changes. g++ is based on gcc, which cannot be ported to L-series (or J-series).
If it's C++14 or later, you're completely out of luck.
On Friday, July 1, 2022 at 12:33:40 PM UTC-7, Randall wrote:I have not yet seen.
On Friday, July 1, 2022 at 11:41:49 a.m. UTC-4, red floyd wrote:
On 7/1/2022 12:11 AM, Keith Dick wrote:
The Google Protocol Buffers package (GPB) is entirely C++. Unless my memory is playing tricks on me, GPB does not depend on any other open source libraries to run, but it does use a number of open source programs in the course of building GPB.
Well, those last two posts are a bit discouraging. Thanks for not holding back on bad news!One note... If it's C++11, you can only build for an L-RVU, not for J. If it's C++14 or later, you're completely out of luck.Big caution that if g++ is required, you are going to have to make a lot of changes. g++ is based on gcc, which cannot be ported to L-series (or J-series).
Is there some fairly simple way to tell whether the C++ source code is C++11, C++14, or some other version? The instructions for building GPB I have found so far do not say anything about what version of C++ it needs. Maybe it will be stated somewhere
What is it about those versions of C++ that prevents them from being compiled on J-series or L-series? Is that only true if certain features of the language are used in the source code, or are those versions of C++ so fundamentally different from whatc89 or c99 can compile that there truly is zero hope?
I was under the impression that g++ was just the name given to the gcc executable when it was to expect C++ syntax in the source files it was given to compile. Is that impression wrong in some way?have the original source files and the modified source files that I finally was able to get to compile. I could use diff to see what all the changes were, but I figured that would not be very helpful, given that I believe 3.x was a rewrite.
I have to say that these warnings do seem to confirm my experience from almost 10 years ago when porting GPB version 2.4.1. I had to make a LOT of changes to the C++ source files, though I don't remember any details of what those changes were. I do
I see a very large number of open source packages in the ITUGLIB open source library. Do none of those packages use gcc or g++? I thought that gcc was the most common compiler in the open source world. If a large number of the ITUGLIB contents did usegcc or g++ in their original environment, how were you able to get them compiled for the NonStop system?
How about the other packages listed as being required to build GPB? Especially autoconf, automake, and libtool. Are there known difficulties in using them on NonStop systems when building other open source packages, or do they work well on NonStopsystems? Any tips or tricks needed to help get them to work on NonStop systems? I recall whatever tools were used in the configure step of building GPB 2.4.1 gave me a huge number of problems 10 years ago.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 298 |
Nodes: | 16 (1 / 15) |
Uptime: | 05:11:09 |
Calls: | 6,671 |
Calls today: | 3 |
Files: | 12,219 |
Messages: | 5,338,828 |