Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix build errors on more recent operating systems #65

Closed
tswilliams opened this issue Oct 19, 2017 · 10 comments
Closed

Fix build errors on more recent operating systems #65

tswilliams opened this issue Oct 19, 2017 · 10 comments
Assignees

Comments

@tswilliams
Copy link
Collaborator

Currently, the IPbus software is only regularly built on SLC6 & CentOS7, and so requires a few minor fixes in order to compile on more recent operating systems, which have more recent versions of g++ and boost - e.g:

  • Ubuntu 16: g++ v5.4.0, boost v1.58.0
  • Fedora 26: g++ v7.2.1, boost v.1.63.0
@tswilliams tswilliams self-assigned this Oct 19, 2017
@tswilliams tswilliams added this to the v2.6.0 release milestone Oct 19, 2017
@PALoizeau
Copy link

Dear IPbus developers,
In the CBM project of GSI/FAIR (in which Wojtek Zabolotny from Warsaw is participating), we are in fact using IPbus/uHAL on Debian and Ubuntu.
We have mainly machines with Debian 8, where we could get the full IPbus software (including controlhub) v2.4.1 and 2.5.2 to compile with only two small modifications:

  • providing the make command with the SHELL=/bin/bash option
  • modifying the Makefile and Makefile.macros to either download Boost v1.57 or use some external boost install with version between 1.57 and 1.59 (can be the system one or the one shipped in our FairSoft bundle)

The same tricks worked for us on some Ubuntu 16.04 computers where we do only code development.

I started investigating compilation on Debian 9 (stretch) some weeks ago because Debian 8 (jessie) will be out of security support next year.
The only problem I found is that the controlhub compilation failed due to some erlang crypto errors. After looking a bit more in detail to the compilation logs, I could see that otp_src_R16B01(which I understand to be erlang) is compiled twice:

  • Once in extern/erlang without ssl support
  • A second time in controlhub with ssl support.

For the second compilation, the openssl version shipped with Debian 9 (v1.1.0) is actually not properly detected or not compatible and erlang-crypto is deactivated at configure stage.
The erlang-crypto package in the same Debian version in fact depends on a downgrade of openssl to v1.0.2.
From the erlang-crypto release notes, this seems to have been resolved in v4.0 (http://erlang.org/doc/apps/crypto/notes.html).

I must confess of being a plain user of controlhub and not knowing anything about erlang, so I am not sure exactly how difficult it would be to upgrade erlang or erlang-crypto in IPbus. But we would be grateful if we could make the full IPbus compatible with this Debian version. Worst case maybe requesting a downgrade to openssl v1.0.2 is the solution, but we would like to avoid it if possible.

If needed I can try applying patches locally and testing compilation/operation as we have a machine dedicated to this.

Best regards
Pierre-Alain

PS: I can also make the compilation logs available if needed.

@dreyling
Copy link

@PALoizeau
Hi Pierre-Alain,
I am also trying to get a proper Ubuntu 16.04 installation, and your report sounds promising!
Could you somehow provide me your "modified Makefile and Makefile.macros" for the alternative Boost installation, which had worked for you?
That would be great, best wishes,
Jan

@tswilliams
Copy link
Collaborator Author

tswilliams commented Nov 13, 2017

@PALoizeau @dreyling
Hi Pierre-Alain, Jan

Thanks for your questions and comments. I have made some structural changes to the IPbus software makefiles over the past couple of months, partly in order to make sure that it's easy to build the software on non-RedHat-based operating systems.

The easiest approach right now for recent non-RedHat-based operating systems such as debian and ubuntu is to install the system-version of boost and erlang (via apt-get or yum), and then use the code from the feature/run-automated-builds-on-more-operating-systems branch of the git repo - i.e:

git clone https://github.com/ipbus/ipbus-software.git
cd ipbus-software
git checkout feature/run-automated-builds-on-more-operating-systems
make Set=all

Could you try running these commands, after installing the system version of boost, pugixml and erlang (sudo apt-get install libboost-all-dev erlang libpugixml-dev), and let me know if you encounter any problems?

These changes simplifying compilation on non-RedHat-based systems will then be included in the next release of the IPbus software, v2.6.0, which will be created around the end of the year.

Cheers,
Tom

@dreyling
Copy link

@tswilliams Thanks for this!

I have tried it, it seems that it works quite far, but ended with that error:
Makefile:55: recipe for target 'controlhub/.virtual.Makefile' failed
Please find the whole log here:
171113_make_log_1st_try.log

However, I was curious and have tried to run your unit test:

source uhal/tests/setup.sh
python ./uhal/tests/scripts/uhal_test_suite.py -v -c uhal/tests/etc/uhal/tests/dummy_connections.xml -s "2.0 udp"

which ended with that: TEST SUITE COMPLETED! 23 commands run, 3 errors (non-zero exit codes)
Please find the whole output here:
171113_uhal_test_suite_output.log

@tswilliams
Copy link
Collaborator Author

@dreyling

Regarding the ControlHub build error: This is a problem in the standard packaging of Erlang on Ubuntu 16.04; a common workaround is:

sudo touch /usr/lib/erlang/man/man1/x86_64-linux-gnu-gcov-tool.1.gz
sudo touch /usr/lib/erlang/man/man1/gcov-tool.1.gz

This should allow the controlhub to be built, but not adversely affect it's functionality. I have tested this fix on the ubuntu docker container that I'm using for development, and they work in my setup; can you try running the above workaround commands, then re-running make Set=all in a fresh copy of the checked-out repo, and let me know if you still see any errors?

Regarding the test suite errors: these all appear to be spurious errors from bugs within the script itself when running on Ubuntu; I'll fix these soon, but the 3 errors within the output that you attached do not indicate any problems within the uHAL libraries themselves.

@dreyling
Copy link

@tswilliams Thank you very much for your quick reply!

I can confirm your proposed installation recipe for this Ubuntu version:

lsb_release -a
 No LSB modules are available.
 Distributor ID:	Ubuntu
 Description:	Ubuntu 16.04.2 LTS
 Release:	16.04
 Codename:	xenial
uname -a
 Linux atlaswin10 4.4.0-98-generic #121-Ubuntu SMP Tue Oct 10 14:24:03 UTC 2017 x86_64 x86_64  x86_64 GNU/Linux

Installation summary:

sudo apt-get install libboost-all-dev erlang libpugixml-dev
sudo touch /usr/lib/erlang/man/man1/x86_64-linux-gnu-gcov-tool.1.gz
sudo touch /usr/lib/erlang/man/man1/gcov-tool.1.gz
git clone https://github.com/ipbus/ipbus-software.git
cd ipbus-software
git checkout feature/run-automated-builds-on-more-operating-systems
make Set=all

@PALoizeau
Copy link

PALoizeau commented Nov 16, 2017

@tswilliams @dreyling Thanks for the info.

The Ubuntu installation branch is also working with these commands for Ubuntu 16.04.3 LTS with GA (4.4. x kernels, long support) and HWE packages (4.10.x kernels, rolling release toward next LTS).
I also ran the test scripts with the same results.

Edit 17/11/2017:
After seeing that the Crypto release with the openssl 1.1 fix is included in OTP 20, I decided to give it a try.
I then managed to compile the master branch on Debian with the following packages:

You can find the modifications I did to use OTP 20 in the attached text file (git diff output).
ipbus_debian9_otp20_1.txt

I could run the test script mentioned above with the same result as on Ubuntu, so I will probably try to run a few tests with our hardware on Monday to see if not only compilation but running is OK.

Are there any points that I should more specifically survey to detect potential problems due to the change to OTP 20?

tswilliams added a commit that referenced this issue Nov 22, 2017
tswilliams added a commit that referenced this issue Nov 23, 2017
…undefined symbol' error on loading python bindings; refs #65
tswilliams added a commit that referenced this issue Nov 23, 2017
@tswilliams
Copy link
Collaborator Author

Hi @PALoizeau ,

This evening I've merged into the master branch a change which fixes a runtime error in the ControlHub when using Erlang 19; I suspect the same error would also affect the ControlHub when using Erlang 20.

My general recommendation for recent operating systems, such as Debian 9, would be to use the system version of boost, pugixml and erlang, unless other versions must be used for compatibility with experiment/other frameworks. To support that approach, a few days ago, I updated the makefiles on the master branch so that boost, pugixml and erlang are not rebuilt by default on all operating systems apart from RHEL 6.

So, my current recommendation for debian 9 would be to use the system versions of boost, pugixml and erlang - or those from your experiment's framework - check out the latest commit from the master branch - 3c8ab8d - and run make Set=all. I have just tried compiling this on a clean debian 9 setup, and the full set of dependencies can be installed using the following command:

apt-get install make git erlang g++ libboost-all-dev libpugixml-dev python-all-dev

If you're using the version of pugixml and/or boost from your experiment's framework, and need to specify the include paths for their headers/libraries, you can do so using the following macros:

  • EXTERN_BOOST_INCLUDE_PREFIX
  • EXTERN_BOOST_LIB_PREFIX
  • EXTERN_PUGIXML_INCLUDE_PREFIX
  • EXTERN_PUGIXML_LIB_PREFIX
    E.g:
make Set=all EXTERN_BOOST_INCLUDE_PREFIX=/path/to/boost/include EXTERN_BOOST_LIB_PREFIX=/path/to/boost/lib

Cheers,
Tom

@PALoizeau
Copy link

Hi @tswilliams,

I indeed had funny runtime timeouts last Friday when using Ipbus with Erlang 20 .
Now after going to the current master, everything works fine as far as I can tell: I did not test massive block read/write so no stressed system, but single OP and small block R/W are tested without any trouble.

I used

  • the system versions of Pugixml and python,
  • the boost version from our experiment framework thanks to the extern options in the make command
  • Erlang 20 with the patches from my previous command and the "BUILD_ERLANG=1" option to the make command.

I will switch our standard IPbus version for users to 2.6 when it is out, and I can now wait completely relaxed for the later time when we have to switch to Debian 9 :-)

Thanks a lot again and best regards,
Pierre-Alain

tswilliams added a commit that referenced this issue Jan 5, 2018
@tswilliams
Copy link
Collaborator Author

tswilliams commented Jan 8, 2018

Hi all,

I'm closing this ticket now, since I'm not aware of any remaining unsolved build errors on recent operating systems, but please re-open this ticket if you're still encountering a build error.

All of the fixes & improvements related to this ticket have been merged into the master branch of the git repo, and are included in the 1st alpha tag for the v2.6.0 release (tag prerelease/v2.6.0/alpha.1). The final (i.e. non alpha/beta) 2.6.0 release will be created later this month.

I've updated the documentation in the user's guide for building and installing from source - specifically http://ipbus.web.cern.ch/ipbus/doc/user/html/software/install/compile.html - to contain all of the information from this ticket (and more that wasn't discussed above). This commands in this page will always reference the latest recommended tag that should be used when compiling + installing from source.

Cheers,
Tom

jhegeman pushed a commit to jhegeman/ipbus-software that referenced this issue Dec 6, 2021
Adding read / write functionality to counter block
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants