javarias commented 10 years ago

As an alternative for some users, it is necessary to port ACS to Ubuntu.

The current Ubuntu version is 14.04 LTS. ubuntu distribution has a newer set of gcc compilers (gcc 4.8.x), which a stricter than the gcc available in RHEL 6.5

javarias commented 10 years ago

A port has been done on my ACS fork: https://github.com/javarias/ACS/tree/ubuntu-port With the set of changes I have done, all the modules, but emacs, build correctly. I have tested basic functionality, but more testing is required.

More details are available here: https://github.com/javarias/ACS/wiki/Ubuntu-port

pdevicente commented 10 years ago

We have downloaded your Ubuntu port and tried to compile the ExtProducts first at Debian Wheezy, (gcc 4.7.2). We have ran into trouble with Mico:

poa_impl.cc: In constructor ‘MICOPOA::POA_impl::POAimpl(const char, PortableServer::POAManager_ptr, const PolicyList&, MICOPOA::POAimpl, CORBA::ORB_ptr)’: poaimpl.cc:1939:80: error: invalid user-defined conversion from ‘const ObjVarCORBA::Policy’ to ‘CORBA::Object’ [-fpermissive] In file included from ../include/CORBA.h:151:0, from poaimpl.cc:38: ../include/mico/template.h:96:3: note: candidate is: ObjVar::operator T() [with T = CORBA::Policy] ../include/mico/template.h:96:3: note: no known conversion for implicit ‘this’ parameter from ‘const ObjVarCORBA::Policy’ to ‘ObjVarCORBA::Policy’ poaimpl.cc:1939:80: error: passing ‘const ObjVarCORBA::Policy’ as ‘this’ argument of ‘ObjVar::operator T() [with T = CORBA::Policy]’ discards qualifiers [-fpermissive] make[2]: _\ [poa_impl.pic.o] Error 1 make[2]: se sale del directorio /home/almamgr/ACS-ubuntu-port/ExtProd/PRODUCTS/mico/orb' make[1]: *** [system] Error 1 make[1]: se sale del directorio/home/almamgr/ACS-ubuntu-port/ExtProd/PRODUCTS/mico'

javarias commented 10 years ago

Yes you are right, mico is not building in ubuntu. I didn't care much about this because mico is used only to validate of the idl files being loaded into the interface repository, which are checked, anyway, when the idl files are compiled for all the programming languages.

Regardless of that, I applied the patch of @tstaig: tstaig/ACS@ca56c7eeff81f90c5607cc7caba6ef5b0095d1a8 There was required an extra patch to to deal with missing linking symbols (see javarias/ACS@b571e58d56af8efb6889ad79b788b4752adc2a25). You can pull these changes from my repository in ubuntu-port branch.

pdevicente commented 9 years ago

We have made very slight modifications to make it work in Debian. I think it would be best if you include them in your branch. The one I point here is regarding JAVA_HOME env variable. If you try to install ACS in a 32 bit distribution it fails because JAVA_HOME is incorrectly set. See below the correction (and a comment in spanish):

LGPL/acsBUILD/config/.acs/.bash_profile.acs:

if [ X"$JAVA_HOME" = X ] || [ X"$ACS_RETAIN" = X ] then if [ "$OSYSTEM" = "$CYGWIN_VER" ] then JAVA_HOME=/Java elif [ "$DISTRO" = "DEBIAN" ] then

bash identifica como asignacion el simbolo '=' pegado a la variable y como comparación cuando este está separado por un espacio

if [ $ARCH="X86_64" ]

if [ "$ARCH" = "x86_64" ] then JAVA_HOME="/usr/lib/jvm/java-7-openjdk-amd64"

elif [ $ARCH="i686" ]

elif [ "$ARCH" = "i686" ] then JAVA_HOME="/usr/lib/jvm/java-7-openjdk-i386" fi else JAVA_HOME=/usr/java/default fi fi

pdevicente commented 9 years ago

The key lines are: if [ "$ARCH" = "x86_64" ] and elif [ "$ARCH" = "i686" ]

pdevicente commented 9 years ago

Second change we made for Debian. In file ExtProd/INSTALL/buildPyModules

replace all occurences of python-ldap-2.3.11.tar.gz by python-ldap-2.4.15.tar.gz
replace all occurences of snakefood-1.4-20100716.tgz by snakefood-1.4.tar.gz

tstaig commented 9 years ago

Hi, there are several different installation paths for the jdk, and you can use either openjdk or oracle (and maybe other implementations). When you do not have a standard Java path the correct way to do this is in your own environment exporting JAVA_HOME before sourcing the ACS .bash_profile.acs file: if [ "$ARCH" = "x86_64" ]; then export JAVA_HOME="/usr/lib/jvm/java-7-openjdk-amd64" elif [ "$ARCH" = "i686" ]; then export JAVA_HOME="/usr/lib/jvm/java-7-openjdk-i386" fi source /LGPL/acsBUILD/config/.acs/.bash_profile.acs -r

Note the '-r' flag which sets the ACS_RETAIN variable in the sourced script in order to persist your own configurations instead of discarding them.

Regards, Tomas.

On 11/13/2014 08:45 AM, Pablo de Vicente wrote:

We have made very slight modifications to make it work in Debian. I think it would be best if you include them in your branch. The one I point here is regarding JAVA_HOME env variable. If you try to install ACS in a 32 bit distribution it fails because JAVA_HOME is incorrectly set. See below the correction (and a comment in spanish):

*
LGPL/acsBUILD/config/.acs/.bash_profile.acs:

if [ X"$JAVA_HOME" = X ] || [ X"$ACS_RETAIN" = X ]
then
if [ "$OSYSTEM" = "$CYGWIN_VER" ]
then
JAVA_HOME=/Java
elif [ "$DISTRO" = "DEBIAN" ]
then
#bash identifica como asignacion el simbolo '=' pegado a la
variable y como comparación cuando este está separado por un espacio
#if [ $ARCH="X86_64" ]
if [ "$ARCH" = "x86_64" ]
then
JAVA_HOME="/usr/lib/jvm/java-7-openjdk-amd64"
#elif [ $ARCH="i686" ]
elif [ "$ARCH" = "i686" ]
then
JAVA_HOME="/usr/lib/jvm/java-7-openjdk-i386"
fi
else
JAVA_HOME=/usr/java/default
fi
fi
— Reply to this email directly or view it on GitHub https://github.com/ACS-Community/ACS/issues/10#issuecomment-62878999.

pdevicente commented 9 years ago

Yes, we know about setting JAVA_HOME this way. This is how we do that since a long time with previous versions of ACS and I believe this is more flexible. I just wanted to point out that .bash_profile.acs has an error and it is that "$ARCH"="x86_64" should be "$ARCH" = "x86_64". The space at both sides of the = is important.

acaproni commented 9 years ago

Hi Matias, what vesion of .bash_profile.acs are you talking about? ACS/ESO version does not have this problem. I have double checked just in case. But we should have spotted already because ACS for 64bit has been released long ago and is also in use.

Chao, Ale

On 11/18/2014 09:26 AM, Pablo de Vicente wrote:

Yes, we know about setting JAVA_HOME this way. This is how we do that since a long time with previous versions of ACS and I believe this is more flexible. I just wanted to point out that .bash_profile.acs has an error and it is that "$ARCH"="x86_64" should be "$ARCH" = "x86_64". The space at both sides of the = is important.

— Reply to this email directly or view it on GitHub https://github.com/ACS-Community/ACS/issues/10#issuecomment-63436530.

javarias commented 9 years ago

You are right Pablo. I made the corrections for both problems you reported here. The commits I did to fix the problems are in javarias/ACS@ac75e4f and javarias/ACS@75904ec in the ubuntu-port branch.

I think the last fix javarias/ACS@75904ec should go into the ACS master branch in the ACS Community repo also.

normansaez commented 9 years ago

Hi Jorge:

I'm testing ubuntu 14.04 , and everything compile smoothly. The problem is that Logging Service got stuck and never starts.

2014-12-07T00:12:49.194 INFO [acsLoggingService] Starting Logging Service

I have this problem in two different virtual machines (fresh installations); both stuck in the same place.

m_logging_supplier returns null for some unknown reason.

543LoggingService::create_suppliers ()
544{
545    if(!m_logBin)
546        m_logging_supplier = new ACSStructuredPushSupplierXml ();
547    else
548        m_logging_supplier = new ACSStructuredPushSupplierBin ();
549
550    ACE_ASSERT (m_logging_supplier);
551
552  m_logging_supplier->connect (this->m_logging_supplier_admin.in ()
553                );
554}

bjeram commented 9 years ago

try to modify/remove "SourceThread" from: $ACSROOT/config/svc.conf/defaultNotify.svc.conf

normansaez commented 9 years ago

Hi Bogdan !

I just tried, and It doesn't work either. I removed the option and also I increase the source threads, but still, logging service never start.

bjeram commented 9 years ago

ok, you can try to comment out the whole line containing "SourceThread" (so the line: static Notify_Default.......), if it does not work try to experiment with other config7uration in $ACSROOT/config/svc.conf/defaultNotify.svc.conf

normansaez commented 9 years ago

Hi Bogdan It doesn't work either. This quite strange, with a fresh ISO image of Xubuntu 14.04, it was compiled, and it worked without any modification. I think better leave this as register and see if the problem appears to someone else, because if nobody has this issue anymore it was something related to my ubuntu's ISO (hopefully)

javarias commented 9 years ago

I tried a fresh build of my branch on xubuntu 14.04.1 and in xubuntu 14.10. I was unable reproduce the problem described by Norman on neither xubuntu versions.

pdevicente commented 9 years ago

We have seen that behaviour 2 weeks ago. It was not myself, but Rubén who is no loger at Yebes, but at the Azores Islands now. We compiled a fresh 2014.4 ACS on a Debian Wheezy 64 bit host. This worked and our components work fine here. Then Rubén did a tar from /alma/ACS-2014.4 from that host and copied it into a laptop with Debian Wheezy 64 bit. He untared the file and, after cleaning the cache and the temp files, he tried to start up the ACS. The logging channel never starts up and ACS boot does not complete.

pdevicente commented 9 years ago

We have seen that behaviour 2 weeks ago. It was not myself, but Rubén who is no loger at Yebes, but at the Azores Islands now. We compiled a fresh 2014.4 ACS on a Debian Wheezy 64 bit host. This worked and our components work fine here. Then Rubén did a tar from /alma/ACS-2014.4 from that host and copied it into a laptop with Debian Wheezy 64 bit. He untared the file and, after cleaning the cache and the temp files, he tried to start up the ACS. The logging channel never starts up and ACS boot does not complete.

2014-12-11 14:56 GMT+01:00 Jorge Avarias notifications@github.com:

I tried a fresh build of my branch on xubuntu 14.04.1 and in xubuntu 14.10. I was unable reproduce the problem described by Norman on neither xubuntu versions.

— Reply to this email directly or view it on GitHub https://github.com/ACS-Community/ACS/issues/10#issuecomment-66621665.

javarias commented 9 years ago

I tried to replicate the problem that @normansaez and @pdevicente reported, but I was unable to replicate the failing acsStart. I just did a fresh installation of Ubuntu 14.04.1 in a Vmware VMm installing on top the needed packages to run ACS.

If any of you could give a VM (it doesn't matter the VM software) on which the problem can be replicated, it would be great!

normansaez commented 9 years ago

@javarias I have a VM with the problem mentioned here. It was build with vmware. Write me how provide it to you.

tzuchiangshen commented 9 years ago

it worked for me! Thank you Bogdan.

try to modify/remove "SourceThread" from: $ACSROOT/config/svc.conf/defaultNotify.svc.conf

normansaez commented 9 years ago

Hi Tzu!

So you just commented out the line indicated by Bogdan and it worked? or you change the configuration a little bit ?

jantogni commented 9 years ago

Hi, I created the machine that Tzu was using.

Initially I created 8gb virtual machine with centos 6.7. After moving the virtual machine to 1gb, this problem appear. With 2gb the problem persist. But with 4gb the problem didn't appear.

javarias commented 8 years ago

The changes to support Ubuntu were merge with pull request #53 I am closing this ticket given the pull request as been accepted

ACS-Community / ACS

Port ACS to Ubuntu #10

bash identifica como asignacion el simbolo '=' pegado a la variable y como comparación cuando este está separado por un espacio

if [ $ARCH="X86_64" ]

elif [ $ARCH="i686" ]

it worked for me! Thank you Bogdan.