Would you consider renaming link.h

[nickez]

Hey Base developers,

I'm managing the dynamic linking of libraries myself which has shown an unfortunate name clash: src/ioc/dbStatic/link.h is clashing with /usr/include/link.h in glibc. Would you consider renaming link.h in future versions of EPICS Base?

I have to use one of the following workarounds currently:
1. Force EPICS includes to a lower priority with USR_INCLUDES = -idirafter ${EPICS_BASE}/include
2. Specify absolute path to link.h in the sources: #include </usr/include/link.h>

http://linux.die.net/include/link.h

[Andrew Johnson (anj)]

Hi Nicke,

That particular header file dates back to 1996 and possibly earlier, and is included by almost every single EPICS record type and device support ever developed (most of which are not included in Base but are provided as separate downloadable modules by their individual authors). Renaming it would therefore cause a *lot* of pain to our users, so I think it's rather unlikely that we would agree to do that.

What exactly are you trying to do? I suspect there may be a different and possibly simpler approach that could solve your problem than the workarounds you describe, but we would need to know more about what you're doing to help you find it.

- Andrew

[nickez (nicke-claesson)]

Hi Andrew,

I'm using dl_iterate_phdr to iterate over loaded libraries. I don't
know of any other ways to do that.

Do you actually think it would be that difficult for EPICS developers
to update a single include?

Like I said, it is not a huge issue since I have at least two workarounds.

I thought you might wanted to know since you are about to bump the
major number and it would be fitting to allow breaking changes in that
kind of version bump.

Personally, I would see it as a bug to have a name conflict with glibc.

Feel free to close this bug :)

Cheers

- Niklas

2016-03-30 22:31 GMT+02:00 Andrew Johnson <email address hidden>:
> Hi Nicke,
>
> That particular header file dates back to 1996 and possibly earlier, and
> is included by almost every single EPICS record type and device support
> ever developed (most of which are not included in Base but are provided
> as separate downloadable modules by their individual authors). Renaming
> it would therefore cause a *lot* of pain to our users, so I think it's
> rather unlikely that we would agree to do that.
>
> What exactly are you trying to do? I suspect there may be a different
> and possibly simpler approach that could solve your problem than the
> workarounds you describe, but we would need to know more about what
> you're doing to help you find it.
>
> - Andrew
>
>
> ** Changed in: epics-base
> Assignee: (unassigned) => Andrew Johnson (anj)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1563841
>
> Title:
> Would you consider renaming link.h
>
> Status in EPICS Base:
> New
>
> Bug description:
> Hey Base developers,
>
> I'm managing the dynamic linking of libraries myself which has shown
> an unfortunate name clash: src/ioc/dbStatic/link.h is clashing with
> /usr/include/link.h in glibc. Would you consider renaming link.h in
> future versions of EPICS Base?
>
> I have to use one of the following workarounds currently:
> 1. Force EPICS includes to a lower priority with USR_INCLUDES = -idirafter ${EPICS_BASE}/include
> 2. Specify absolute path to link.h in the sources: #include </usr/include/link.h>
>
> http://linux.die.net/include/link.h
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/epics-base/+bug/1563841/+subscriptions

[Andrew Johnson (anj)]

Hi Nicklas,

So you're writing some code that needs to include the system's link.h header file, but the EPICS header file of the same name is getting in the way. 2 questions:
  1. Could you move that code into a source file that doesn't also need any EPICS header files?
  2. Are you using the EPICS build system to compile this?
If the answer to both those questions is Yes you can empty the list of include directories used when compiling that one file (which I'll name needs_link.c) in your Makefile by adding the following line to the *bottom* of the Makefile (after the line that includes configure/RULES):

needs_link.o: INCLUDES=

This uses the target-specific variables feature of GNUmake. You can also put your own list of include directory arguments in there like this:

needs_link.o: INCLUDES = -I. -I.. -I/opt/something/include

HTH,

- Andrew

[nickez (nicke-claesson)]

Hi Andrew,

That is a nice third way to solve it.

Thanks

Den ons 30 mar 2016 23:56Andrew Johnson <email address hidden> skrev:

> Hi Nicklas,
>
> So you're writing some code that needs to include the system's link.h
> header file, but the EPICS header file of the same name is getting in the
> way. 2 questions:
> 1. Could you move that code into a source file that doesn't also need
> any EPICS header files?
> 2. Are you using the EPICS build system to compile this?
> If the answer to both those questions is Yes you can empty the list of
> include directories used when compiling that one file (which I'll name
> needs_link.c) in your Makefile by adding the following line to the *bottom*
> of the Makefile (after the line that includes configure/RULES):
>
> needs_link.o: INCLUDES=
>
> This uses the target-specific variables feature of GNUmake. You can also
> put your own list of include directory arguments in there like this:
>
> needs_link.o: INCLUDES = -I. -I.. -I/opt/something/include
>
> HTH,
>
> - Andrew
>
>
> ** Changed in: epics-base
> Status: New => Won't Fix
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1563841
>
> Title:
> Would you consider renaming link.h
>
> Status in EPICS Base:
> Won't Fix
>
> Bug description:
> Hey Base developers,
>
> I'm managing the dynamic linking of libraries myself which has shown
> an unfortunate name clash: src/ioc/dbStatic/link.h is clashing with
> /usr/include/link.h in glibc. Would you consider renaming link.h in
> future versions of EPICS Base?
>
> I have to use one of the following workarounds currently:
> 1. Force EPICS includes to a lower priority with USR_INCLUDES =
> -idirafter ${EPICS_BASE}/include
> 2. Specify absolute path to link.h in the sources: #include
> </usr/include/link.h>
>
> http://linux.die.net/include/link.h
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/epics-base/+bug/1563841/+subscriptions
>

[mdavidsaver (mdavidsaver)]

FYI error.h also collides glibc.

I agree that an immediate rename is out of the question. Is it worthwhile to add new headers as alternative names to start a migration? maybe epicsLink.h and epicsError.h?

[Andrew Johnson (anj)]

Our error.h header is somewhat obscure and will go away if/when I finish my register-errsyms development (not yet published).

Our link.h is an IOC-specific header so would never be named epicsLink.h (the epics prefix should only be used for libCom APIs) — the only IOC-specific header with epics in the name right now is epicsRelease.h and should be renamed coreRelease.h anyway. We already have a dbLink.h which includes link.h but it's in ioc/db not ioc/dbStatic; I'll have a think about this sometime.

[nickez (nicke-claesson)]

You could also consider to use a prefix like epics/link.h or ioc/link.h, I
don't really know what would be an appropriate prefix though. I noticed
that all the v4 headers have the pretty broad "pv" prefix.

Den tors 31 mar 2016 19:05Andrew Johnson <email address hidden> skrev:

> Our error.h header is somewhat obscure and will go away if/when I finish
> my register-errsyms development (not yet published).
>
> Our link.h is an IOC-specific header so would never be named epicsLink.h
> (the epics prefix should only be used for libCom APIs) — the only IOC-
> specific header with epics in the name right now is epicsRelease.h and
> should be renamed coreRelease.h anyway. We already have a dbLink.h which
> includes link.h but it's in ioc/db not ioc/dbStatic; I'll have a think
> about this sometime.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1563841
>
> Title:
> Would you consider renaming link.h
>
> Status in EPICS Base:
> Won't Fix
>
> Bug description:
> Hey Base developers,
>
> I'm managing the dynamic linking of libraries myself which has shown
> an unfortunate name clash: src/ioc/dbStatic/link.h is clashing with
> /usr/include/link.h in glibc. Would you consider renaming link.h in
> future versions of EPICS Base?
>
> I have to use one of the following workarounds currently:
> 1. Force EPICS includes to a lower priority with USR_INCLUDES =
> -idirafter ${EPICS_BASE}/include
> 2. Specify absolute path to link.h in the sources: #include
> </usr/include/link.h>
>
> http://linux.die.net/include/link.h
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/epics-base/+bug/1563841/+subscriptions
>