"error: ‘epicsShareFunc’ does not name a type" when building latest tagged release

[bsobhani]

When I try to compile synapps with the following (these are all the current defaults):

SUPPORT=R6-2-1

ALLENBRADLEY=2.3
ALIVE=R1-3-1
AREA_DETECTOR=R3-11
ASYN=R4-42
AUTOSAVE=R5-10-2
BUSY=R1-7-3
CALC=R3-7-4
CAMAC=R2-7-4
CAPUTRECORDER=R1-7-4
DAC128V=R2-10-1
DELAYGEN=R1-2-3
DXP=R6-0
DXPSITORO=R1-2
DEVIOCSTATS=3.1.16
ETHERIP=ether_ip-3-2
GALIL=V3-6
IP=R2-21-1
IPAC=2.16
IP330=R2-10
IPUNIDIG=R2-12
LOVE=R3-2-8
LUA=R3-0-2
MCA=R7-9
MEASCOMP=R2-5-1
MODBUS=R3-2
MOTOR=R7-2-2
OPCUA=v0.9.3
OPTICS=R2-13-5
QUADEM=R9-4
SNCSEQ=2.2.9
SOFTGLUE=R2-8-3
SOFTGLUEZYNQ=R2-0-4
SSCAN=R2-11-5
SCALER=4.0
STD=R3-6-3
STREAM=2.8.22
VAC=R1-9-1
VME=R2-9-4
YOKOGAWA_DAS=R2-0-1
XSPRESS3=2-5
XXX=R6-2-1

and using epics base R7.0.6.1, I get the following compilation error message from motor record:

In file included from ../motordevCom.cc:70:
../motordrvCom.h:221:1: error: ‘epicsShareFunc’ does not name a type
  221 | epicsShareFunc RTN_STATUS motor_send(struct mess_node *, struct driver_table *);
      | ^~~~~~~~~~~~~~
../motordrvCom.h:221:1: note: the macro ‘epicsShareFunc’ had not yet been defined
In file included from ../motordevCom.cc:73:
/home/q8i/epics/base/include/shareLib.h:169: note: it was later defined here
  169 | #   define epicsShareFunc __attribute__ ((visibility("default")))
      | 
In file included from ../motordevCom.cc:70:
../motordrvCom.h:222:1: error: ‘epicsShareFunc’ does not name a type
  222 | epicsShareFunc int motor_free(struct mess_node *, struct driver_table *);
      | ^~~~~~~~~~~~~~
../motordrvCom.h:222:1: note: the macro ‘epicsShareFunc’ had not yet been defined
In file included from ../motordevCom.cc:73:
/home/q8i/epics/base/include/shareLib.h:169: note: it was later defined here
  169 | #   define epicsShareFunc __attribute__ ((visibility("default")))
      | 
In file included from ../motordevCom.cc:70:
../motordrvCom.h:223:1: error: ‘epicsShareFunc’ does not name a type
  223 | epicsShareFunc int motor_card_info(int, MOTOR_CARD_QUERY *, struct driver_table *);
      | ^~~~~~~~~~~~~~
../motordrvCom.h:223:1: note: the macro ‘epicsShareFunc’ had not yet been defined
In file included from ../motordevCom.cc:73:
/home/q8i/epics/base/include/shareLib.h:169: note: it was later defined here
  169 | #   define epicsShareFunc __attribute__ ((visibility("default")))
      | 
In file included from ../motordevCom.cc:70:
../motordrvCom.h:224:1: error: ‘epicsShareFunc’ does not name a type
  224 | epicsShareFunc int motor_axis_info(int, int, MOTOR_AXIS_QUERY *, struct driver_table *);
      | ^~~~~~~~~~~~~~
../motordrvCom.h:224:1: note: the macro ‘epicsShareFunc’ had not yet been defined
In file included from ../motordevCom.cc:73:
/home/q8i/epics/base/include/shareLib.h:169: note: it was later defined here
  169 | #   define epicsShareFunc __attribute__ ((visibility("default")))
      | 
In file included from ../motordevCom.cc:70:
../motordrvCom.h:225:1: error: ‘epicsShareFunc’ does not name a type
  225 | epicsShareFunc int motor_task(struct thread_args *);
      | ^~~~~~~~~~~~~~
../motordrvCom.h:225:1: note: the macro ‘epicsShareFunc’ had not yet been defined
In file included from ../motordevCom.cc:73:
/home/q8i/epics/base/include/shareLib.h:169: note: it was later defined here
  169 | #   define epicsShareFunc __attribute__ ((visibility("default")))

But when instead of using the tagged version I clone the master branch of motor record, and use the same release file, it compiles without issue.

[MarkRivers]

That was fixed in this commit: 784e41927b942d38c31a766309668d6114861b9e on April 19, 2021.

R7-2-2 is from February 2, 2021 so it is not in that release.

[sjstein]

That was fixed in this commit: 784e419 on April 19, 2021.

R7-2-2 is from February 2, 2021 so it is not in that release.

It appears to me that as of 11-July-2022 and using the assemble_synApps.sh bash script to do a lot of the heavy-lifting for grabbing source files, this issue still exists.

e.g. I did a fresh install of synapps using the assemble_synApps.sh script, modified the RELEASE file and did a make. The same errors as OP came up during (attempted) compilation of motordevCom.cc

Is this simply a pull-request needing to be made?

[MarkRivers]

I did a fresh install of synapps using the assemble_synApps.sh script, modified the RELEASE file and did a make. The same errors as OP came up during (attempted) compilation of motordevCom.cc

Are you talking about this version of assemble_synApps.sh: https://github.com/EPICS-synApps/support/blob/master/assemble_synApps.sh

That still uses motor R7-2-2, which is still the most recent motor release.

Is this simply a pull-request needing to be made?

No, there is no need for a pull-request, I have already made the commit on the master branch. All that it needed is for someone to make new tag of the motor module, e.g. R7-2-3 or R7-3.

For now you can just do the following:

cd support/motor-7-2-2
git checkout master
git pull

That may not work if you did not run assemble_synApps.sh with the "full" argument to get full clones. In that case you may need to do a fresh full clone of motor.

git clone --recursive https://github.com/epics-modules/motor

[sjstein]

@MarkRivers - thanks for the info. For this particular fix, I just modified the local source file to add the include.

I was posting the question more as a public service in that others may encounter the same issue until the tag is updated - I realize now the issue is rooted a bit deeper than than at the synapps/support repo.

In summary, when I cloned the synapps/support repo with: git clone https://github.com/EPICS-synApps/support.git

the assemble_synApps.sh does its thing and eventually fails with this issue #187

But I guess the root-cause is the tag within the motor record repo, so there is nothing that can (or should) be done from the synApps perspective?

[kmpeters]

No, there is no need for a pull-request, I have already made the commit on the master branch. All that it needed is for someone to make new tag of the motor module, e.g. R7-2-3 or R7-3.

This is on my TODO list. I'm currently drowning in other issues, though.

[kmpeters]

I will be tagging a new release very soon.

[kmpeters]

Fixed in R7-3