On Mon, Feb 17, 2020 at 2:59 PM Bruno Wolff III <bruno@xxxxxxxx> wrote: > For greyhounds, I didn't make an exception in the include file, but rather > added definitions to the main unit to reserve the space (and changed the > include file to add extern to the definitions). This didn't result in a > conflict, so I'm guessing it was a correct way to do this. If it wasn't, > I'd like to know? That sounds right. I've fixed quite a few of these already. They tend to fall into just a few cases. Case 1. Like the example above: there are non-extern variable declarations in header files, and no non-extern definition in any C/C++ file. Solution: do what Bruno did. Add "extern" to the header file declarations, and add a non-extern definition to some C/C++ file; it doesn't really matter which one, although it should be one that actually accesses the variable in question. Case 2. There are non-extern variable declarations in header files and C/C++ files both. Solution: add "extern" to the header file declarations and make sure there is only one non-extern definition in a C/C++ file. If there is more than one, try removing the others (hopefully they #include the necessary header file). If that doesn't work, either add the necessary #include or add extern to the duplicate definitions. Case 3. A variable is not mentioned in any header file, but there are multiple non-extern definitions of it in C/C++ files. Solution: check the code to see if the variable is supposed to be shared. I have found a few cases where it is not, and the correct solution was to add "static" to each of the definitions. Otherwise, either add an extern declaration to some header file and remove all but one of the non-extern definitions, or add extern to all but one of the definitions. Case 4. Your package is a code generator that spews forth thousands of duplicate variable definitions, trusting in -fcommon to merge them all. Solution: sit on the floor and cry for awhile, then play "First World Problems" by Weird Al, and then contact upstream and inform them that their code generator has a defect, and would they please fix it? (I have 1 package in this category.) Richard, if you will provide a list of your packages that have this issue, some of us may be able to help you put together patches to send upstream. Regards, -- Jerry James http://www.jamezone.org/ _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
