Experimental Physics and
Industrial Control System

Rong Huang via Tech-talk <tech-talk at aps.anl.gov> · Wed, 10 Jan 2024 17:27:32 -0600

Mark,

Sorry it took me a while to get back to you.

quadEM-R7-0 works fine on linux-x86_64 machine, even with asyn-4-36.
Thank you Mark for the help!

As for my original problem with linux-arm, part of the reason was I
ran "TetrAMM.cmd" directly without running "st.cmd". However inside
linux-x86_64, when I made the same mistake, instead of simply crash,
there was message telling me missing something like "asynIPPort"
(don't remember the exact word) which reminded me what I did wrong.
(Later on, I tried running "st.cmd" inside linux-arm, still crash
without much information about what was wrong).

Thanks,
Rong

On Wed, Dec 20, 2023 at 12:29 PM Mark Rivers <rivers at cars.uchicago.edu> wrote:
>
> This is the command that compiles asynPortDriver.cpp, which is where the try/catch block is:
>
> /usr/bin/g++ -c  -D_GNU_SOURCE -D_DEFAULT_SOURCE           -DUNIX  -Dlinux     -O3 -g   -Wall           -fPIC -MMD -I. -I../O.Common -I. -I../../asyn/drvAsynSerial/os/Linux -I../../asyn/drvAsynSerial/os/default -I.. -I../../asyn/asynDriver -I../../asyn/asynGpib -I../../asyn/drvAsynSerial -I../../asyn/interfaces -I../../asyn/miscellaneous -I../../asyn/asynPortDriver/exceptions -I../../asyn/asynPortDriver -I../../asyn/asynPortClient -I../../asyn/devEpics -I../../asyn/asynRecord -I../../asyn/vxi11 -I../../asyn/gsIP488 -I../../asyn/ni1014 -I../../asyn/devGpib -I../../include/os/Linux -I../../include    -I/epicsioc/used/epics/synApps/ipac-2-15/include  -I/epicsioc/used/epics/synApps/seq-2-2-7/include -I/epicsioc/used/epics/base-3.14.12.8/include/os/Linux -I/epicsioc/used/epics/base-3.14.12.8/include      -I/usr/include/tirpc  ../../asyn/asynPortDriver/asynPortDriver.cpp
>
> This is the output when it builds the testAsynPortDriver application:
>
> /usr/bin/g++ -o testAsynPortDriver  -L/epicsioc/used/epics/synApps_5_8_3_14_8/asyn-R4-30/lib/linux-arm -L/epicsioc/used/epics/base-3.14.12.8/lib/linux-arm -Wl,-rpath,/epicsioc/used/epics/synApps_5_8_3_14_8/asyn-R4-30/lib/linux-arm -Wl,-rpath,/epicsioc/used/epics/base-3.14.12.8/lib/linux-arm                     testAsynPortDriver_registerRecordDeviceDriver.o testAsynPortDriverMain.o    -ltestAsynPortDriverSupport -lasyn -lrecIoc -lsoftDevIoc -lmiscIoc -lrsrvIoc -ldbtoolsIoc -lasIoc -ldbIoc -lregistryIoc -ldbStaticIoc -lca -lCom
>
> I don't see anything unusual here, these look like the standard options.
>
> I will be very interested to see what happens when you run the exact same versions of each module on the linux-x86_64 architecture, rather than linux-arm.
>
> Mark
>
> -----Original Message-----
> From: Rong Huang <ronghuang at ls-cat.org>
> Sent: Wednesday, December 20, 2023 11:45 AM
> To: Mark Rivers <rivers at cars.uchicago.edu>
> Cc: Érico Nogueira Rolim <erico.rolim at lnls.br>; tech-talk at aps.anl.gov
> Subject: Re: quadEM-R7-0 ParamValNotDefined
>
> Hello Mark,
>
> The attached file is the complete output of a "re-compiling" of asyn-R4-30.
>
> Thanks,
> Rong
>
> On Wed, Dec 20, 2023 at 10:22 AM Mark Rivers <rivers at cars.uchicago.edu> wrote:
> >
> > Rong,
> >
> > Can you send the complete output when rebuilding the asyn module?  We can then see what compiler flags are being used.
> >
> > Mark
> >
> >
> > -----Original Message-----
> > From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Rong Huang via Tech-talk
> > Sent: Wednesday, December 20, 2023 9:59 AM
> > To: Érico Nogueira Rolim <erico.rolim at lnls.br>
> > Cc: tech-talk at aps.anl.gov
> > Subject: Re: quadEM-R7-0 ParamValNotDefined
> >
> > Perhaps this information is related to your conversation. In my VM, the printout of "g++ --version" is:
> >
> > g++ (GCC) 11.4.1 20230605 (Red Hat 11.4.1-2)
> > Copyright (C) 2021 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> >
> > Thanks,
> > Rong
> >
> > On Wed, Dec 20, 2023 at 6:40 AM Érico Nogueira Rolim <erico.rolim at lnls.br> wrote:
> > >
> > > On 20/12/2023 06:34, Ralph Lange via Tech-talk wrote:
> > >
> > > On Wed, 20 Dec 2023 at 01:23, Mark Rivers via Tech-talk <tech-talk at aps.anl.gov> wrote:
> > >>
> > >>
> > >>
> > >> Note that it is calling paramVal::getInteger in a try/catch block that explicitly catches the exception you are getting, ParamValNotDefined.  So I don't understand why this is causing your program to terminate, rather than simply catching the error and return and error status.
> > >>
> > >>
> > >>
> > >> It seems like perhaps there is something different about the way C++ exception handling works with the linux-arm architecture?  No one has ever reported this error before, but most people are using linux-x86_64.
> > >
> > >
> > > Just poking...
> > >
> > > Inside the ARM toolchain doc [1] I found that
> > >>
> > >> The ARM compilation tools fully support C++ exception handling. However, the compiler does not support this by default. You must enable C++ exception handling with the --exceptions option.
> > >
> > > Far too obvious to be the cause, is it?
> > >
> > >
> > > I don't think that it would be, because any reasonable Linux ARM system would be using GNU (or Clang) compilers, not the ARM compiler suite. "--exceptions" doesn't look like a GCC option either, and Linux userspace as a whole would be broken if built with "-fno-exceptions".
> > >
> > >
> > >
> > > Cheers,
> > > ~Ralph
> > >
> > > [1] https://developer.arm.com/documentation/dui0491/i/C-and-C---Implementation-Details/C---exception-handling#:~:text=The%20ARM%20compilation%20tools%20fully,%2D%2Dno_exceptions%20for%20more%20information.
> > >
> > >
> > >
> > > Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual consulta ao remetente antes de copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem por engano, por favor avise o remetente e apague-a imediatamente.
> > >
> > > Disclaimer: This email and its attachments may contain confidential and/or privileged information. Observe its content carefully and consider possible querying to the sender before copying, disclosing or distributing it. If you have received this email by mistake, please notify the sender and delete it immediately.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System