error: use of undeclared identifier 'AVRDUDE_FULL_VERSION' #1706

dl8dtl · 2024-02-25T07:38:51Z

          I'm not sure, but I think this is somehow related to this PR …

Everything works fine when I rund build.sh on a clone of the official AVRDUDE repo.
However, when running it on my private fork (where the official repo is only upstream remote), even with the same source tree as the official repo, I eventually get:

[ 94%] Built target libavrdude
[ 96%] Building C object src/CMakeFiles/avrdude.dir/main.c.o
/home/joerg/src/avrdude/src/main.c:55:23: error: use of undeclared identifier 'AVRDUDE_FULL_VERSION'
char * version      = AVRDUDE_FULL_VERSION;

Originally posted by @dl8dtl in #1681 (comment)

The text was updated successfully, but these errors were encountered:

dl8dtl · 2024-02-25T07:40:30Z

Just turning it into an issue for easier tracking.
My current fork has stashed changes I'd like to preserve (but not commit yet), so cloning the repo anew isn't a good solution for me.
Also, I think we'd better know the reason for why this happens. Alas, I couldn't understand within 5 minutes last night what's going on here. ;-)

dl8dtl · 2024-02-25T07:47:49Z

For reference, here's the verbose build output for
./build.sh -f -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
logfile.txt

mcuee · 2024-02-25T11:59:21Z

I can reproduce the issue under Windows MSYS2 mingw64 build environment.

Improve autotool build (part 1/n) #1681 (comment)

Repost of the above comment below.

Interestingly I just reproduced your issue under MSYS2 mingw64 with clone from official avrdude, and the solution is the same -- redo the clone. I am not so sure what is the issue though. Occassionally there is the issue of getting wrong version number. And the solution has always the same for me -- to delete the local repo and clone again.

Note: I have delete the build directory before the build but it does not help.

MINGW64 /c/work/avr/avrdude_test/avrdude_main
$ rm -rf build_mingw64_nt-10.0-22631/

$ ./build.sh
-- Building for: Ninja
-- The C compiler identification is GNU 13.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/msys64/mingw64/bin/cc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found Git: C:/msys64/usr/bin/git.exe (found version "2.43.0")
-- Found FLEX: C:/msys64/usr/bin/flex.exe (found version "2.6.4")
-- Found BISON: C:/msys64/usr/bin/bison.exe (found version "3.8.2")
-- Looking for libelf.h
-- Looking for libelf.h - found
-- Looking for libelf/libelf.h
-- Looking for libelf/libelf.h - found
-- Looking for usb.h
-- Looking for usb.h - not found
-- Looking for lusb0_usb.h
-- Looking for lusb0_usb.h - found
-- Looking for libusb.h
-- Looking for libusb.h - not found
-- Looking for libusb-1.0/libusb.h
-- Looking for libusb-1.0/libusb.h - found
-- Looking for hidapi/hidapi.h
-- Looking for hidapi/hidapi.h - found
-- Looking for ftdi_tcioflush
-- Looking for ftdi_tcioflush - found
-- Configuration summary:
-- ----------------------
-- DO HAVE    libelf
-- DO HAVE    libusb
-- DO HAVE    libusb_1_0
-- DO HAVE    libhidapi
-- DON'T HAVE libftdi
-- DO HAVE    libftdi1
-- DO HAVE    libreadline
-- DO HAVE    libserialport
-- DISABLED   doc
-- DISABLED   parport
-- DISABLED   linuxgpio
-- DISABLED   linuxspi
-- ----------------------
-- Configuring done (9.3s)
-- Generating done (0.0s)
-- Build files have been written to: C:/work/avr/avrdude_test/avrdude_main/build_mingw64_nt-10.0-22631
[64/77] Building C object src/CMakeFiles/avrdude.dir/main.c.obj
FAILED: src/CMakeFiles/avrdude.dir/main.c.obj
C:\msys64\mingw64\bin\cc.exe -DCONFIG_DIR="\"C:/Program Files (x86)/avrdude/etc\"" -IC:/work/avr/avrdude_test/avrdude_main/build_mingw64_nt-10.0-22631/src -IC:/work/avr/avrdude_test/avrdude_main -IC:/work/avr/avrdude_test/avrdude_main/build_mingw64_nt-10.0-22631 -IC:/work/avr/avrdude_test/avrdude_main/src -IC:/msys64/mingw64/include/libusb-compat -O2 -g -DNDEBUG -std=gnu11 -Wall -Wextra -Wno-unused-parameter -MD -MT src/CMakeFiles/avrdude.dir/main.c.obj -MF src\CMakeFiles\avrdude.dir\main.c.obj.d -o src/CMakeFiles/avrdude.dir/main.c.obj -c C:/work/avr/avrdude_test/avrdude_main/src/main.c
C:/work/avr/avrdude_test/avrdude_main/src/main.c:55:23: error: 'AVRDUDE_FULL_VERSION' undeclared here (not in a function)
   55 | char * version      = AVRDUDE_FULL_VERSION;
      |                       ^~~~~~~~~~~~~~~~~~~~
[73/77] Building C object src/CMakeFiles/avrdude.dir/developer_opts.c.obj
ninja: build stopped: subcommand failed.
Build failed.

Once I reclone the repo, it works fine,

MINGW64 /c/work/avr/avrdude_test/avrdude_main
$ ./build.sh
-- Building for: Ninja
-- The C compiler identification is GNU 13.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/msys64/mingw64/bin/cc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found Git: C:/msys64/usr/bin/git.exe (found version "2.43.0")
-- Found FLEX: C:/msys64/usr/bin/flex.exe (found version "2.6.4")
-- Found BISON: C:/msys64/usr/bin/bison.exe (found version "3.8.2")
-- Looking for libelf.h
-- Looking for libelf.h - found
-- Looking for libelf/libelf.h
-- Looking for libelf/libelf.h - found
-- Looking for usb.h
-- Looking for usb.h - not found
-- Looking for lusb0_usb.h
-- Looking for lusb0_usb.h - found
-- Looking for libusb.h
-- Looking for libusb.h - not found
-- Looking for libusb-1.0/libusb.h
-- Looking for libusb-1.0/libusb.h - found
-- Looking for hidapi/hidapi.h
-- Looking for hidapi/hidapi.h - found
-- Looking for ftdi_tcioflush
-- Looking for ftdi_tcioflush - found
-- Configuration summary:
-- ----------------------
-- DO HAVE    libelf
-- DO HAVE    libusb
-- DO HAVE    libusb_1_0
-- DO HAVE    libhidapi
-- DON'T HAVE libftdi
-- DO HAVE    libftdi1
-- DO HAVE    libreadline
-- DO HAVE    libserialport
-- DISABLED   doc
-- DISABLED   parport
-- DISABLED   linuxgpio
-- DISABLED   linuxspi
-- ----------------------
-- Configuring done (6.0s)
-- Generating done (0.0s)
-- Build files have been written to: C:/work/avr/avrdude_test/avrdude_main/build_mingw64_nt-10.0-22631
[77/77] Linking C executable src\avrdude.exe

Build succeeded.

Run

sudo cmake --build build_mingw64_nt-10.0-22631 --target install

to install.

mcuee · 2024-02-25T12:05:30Z

I do not think this issue is directly linked to @ndim's PR #1681.

Improve autotool build (part 1/n) #1681

It may have something to do with git and avrdude's build script.

As mentioned before, I've encounter below issue as well under MSYS2 mingw64 and macOS Homebrew (Mac Mini M1). Re-clone the repo will sort out the issue.

avrdude binary has the wrong date info whereas avrdude.conf has the right date and git commit info.

ndim · 2024-02-25T16:09:34Z

How it is supposed to work

The first line of code in src/main.c is #include "ac_cfg.h" which on cmake builds, is actually generated by cmake from src/cmake_config.h.in and put into ${builddir}/src/ac.cfg.h.

There is no complaint from the C preprocessor that it cannot find ac_cfg.h, so the C preprocessor finds an ac_cfg.h somewhere in its include path.

The line in ac_cfg.h we are looking for is the #define AVRDUDE_FULL_VERSION line, and that is created from the cmake-config.h.in file's line

#define AVRDUDE_FULL_VERSION "@AVRDUDE_FULL_VERSION@"

which was added by me in PR #1681 commit cc94578 where I effectively just renamed that line from the old

#define VERSION "@AVRDUDE_FULL_VERSION@"

to make it clearer which kind of version an occurrence of VERSION somewhere in a C file refers to.

What happens on your system?

On my FreeBSD system, after a cmake -S . -B build_freebsd (or the corresponding cmake call from build.sh) I get a working ac_cfg.h:

% grep 'VERSION' build_freebsd/src/ac_cfg.h
#define AVRDUDE_FULL_VERSION "7.3-20240225 (20788712)"

@dl8dtl I presume in your affected private fork working dir, this same grep yields the following. Or is the version older?

% grep 'VERSION' build_freebsd/src/ac_cfg.h
#define VERSION "7.3-20240225 (20788712)"

Then the next check would be

% grep 'VERSION' src/cmake_config.h.in     
#define AVRDUDE_FULL_VERSION "@AVRDUDE_FULL_VERSION@"

which in your case might be

% grep 'VERSION' src/cmake_config.h.in     
#define VERSION "@AVRDUDE_FULL_VERSION@"

Unfortunately, the build logs never mention ac_cfg or cmake_config anywhere.

Maybe it could help forcing cmake to rebuild ac_cfg.h by removing build_freebsd/src/ac_cfg.h but @mcuee writes on his windows build he had the same problem even after removing the build directory...

I cannot see how src/main.c would be updated to use AVRDUDE_FULL_VERSION instead of VERSION, while src/cmake_config.h.in would still use VERSION, as that a single commit changing both.

Shooting in the dark, maybe running grep -r '\<VERSION\>' could help find the VERSION without AVRDUDE_FULL_VERSION (alongside many false positives from autotools generated build files).

Worst case, send me a tarball of the offending directory including all your local and private data. That would give me all your git history, stashes, and local files with weird stuff. (Note to self: Check that I can receive mails with 30+MB attachments.)

dl8dtl · 2024-02-25T19:13:25Z

There is no complaint from the C preprocessor that it cannot find ac_cfg.h, so the C preprocessor finds an ac_cfg.h somewhere in its include path.

That was actually the key to understand it.
The setup that works:

% find . -name ac_cfg.h
./build_freebsd/src/ac_cfg.h

The failing one:

% find . -name ac_cfg.h
./build_freebsd/src/ac_cfg.h
./src/ac_cfg.h

The src/ac_cfg.h file is presumably a leftover from an old non-CMake build. A gmake -i distclean removed all the remnants from the old autoconf build – and voila, build.sh works now.
Thanks for the insight!

ndim · 2024-02-25T19:14:01Z

Is it possible you have an older src/ac_cfg.h file lying around, e.g. from testing autotools builds? That could mistakenly be picked up instead of the proper build_freebsd/src/ac_cfg.h.

ndim · 2024-02-25T19:16:33Z

The two above comments are a good example for a race condition.

Anyway, thanks for pointing this out. There should be an automatic check for this kind of thing.

ndim · 2024-02-25T19:39:59Z

Wait a minute. There should not be a need for such a check.

The C preprocessor should just search the build_$ostype/src/ directory before the src/ directory when looking for a *.h file.

dl8dtl · 2024-02-25T21:12:27Z

Wait a minute. There should not be a need for such a check.

The C preprocessor should just search the build_$ostype/src/ directory before the src/ directory when looking for a *.h file.

OK, I reopen the issue tracker then. Alas, I don't have time right now for any testing.

ndim · 2024-02-25T21:21:33Z

Working on it. Two avenues of attack:

Add a check for the presence of such files to src/CMakeLists.txt which contains all three instances of configure_file(...). Maybe replace configure_file(...) with a custom function which internally calls configure_file but also checks for the presence of rogue files and aborts the build if one is found.
Fix the sequence of directories where the C preprocessor looks for an #include file. The C standards just say the sequence is implementation defined, so that is not much help here. The cmake include_directories only creates -I arguments, not with any special -iquote etc. So this might turn out to be as simple as replacing #include "ac_cfg.h" with #include <ac_cfg.h>.

As an aside, this also explains the following occasional error which I have not tracked down completely yet, but it always happens after I have cleaned out all files from the working dir using git clean -f -d -x and then run ./build.sh -j$(nproc):

CMake Error at src/CMakeLists.txt:155 (add_library):
  Cannot find source file:

    ac_cfg.h

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm
  .ccm .cxxm .c++m .h .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90
  .f95 .f03 .hip .ispc


CMake Error at src/CMakeLists.txt:155 (add_library):
  No SOURCES given to target: libavrdude

ndim · 2024-02-25T22:19:41Z

Quoting section "2.3 Search Path" from cpp.info which is part of GCC cpp-13.2.1:

By default, the preprocessor looks for header files included by the
quote form of the directive #include "FILE" first relative to the
directory of the current file, and then in a preconfigured list of
standard system directories. For example, if /usr/include/sys/stat.h
contains #include "types.h", GCC looks for types.h first in
/usr/include/sys, then in its usual search path.

For the angle-bracket form #include <FILE>, the preprocessor’s
default behavior is to look only in the standard system directories.
The exact search directory list depends on the target system, how GCC is
configured, and where it is installed.

So by using the quote form #include "ac_cfg.h" in src/main.c (and other places), we told the preprocessor to look in the same directory where src/main.c is located, so if there is a leftover ac_cfg.h in src/, the build_$ostype/src/ac_cfg.h is ignored.

The sequence of -I is already good (build dirs before source dirs), so we need to stop using the quote form includes for the generated ac_cfg.h and use angle brackets #include <ac_cfg.h> everywhere.

For static *.h files from src/ (i.e. not generated at build time and placed into build_$ostype/src/), we can continue to use the quote form (e.g. #include "libavrdude.h" in src/*.c).

ndim · 2024-02-25T22:49:57Z

And for balance, MSVC appears to do basically the same. Quoting https://learn.microsoft.com/en-us/cpp/build/reference/i-additional-include-directories?view=msvc-170:

The compiler searches directories in the following order:

If the #include directive is specified using double-quote form, it first searches local directories. The search begins in the same directory as the file that contains the #include directive. If it fails to find the file, it searches next in the directories of the currently opened include files, in the reverse order in which they were opened. The search begins in the directory of the parent include file and continues upward through the directories of any grandparent include files.

If the #include directive is specified in angle-bracket form, or if the local directory search has failed, it searches directories specified by using the /I option, in the order they're specified on the command line.

Directories specified in the INCLUDE environment variable.

mcuee · 2024-02-25T23:29:51Z

@ndim

Wonderful analysis.

I have lived with the issue for a long time, as I tested with both CMake (more often) and autotools build (occassionally). It is great now that the root cause has been found.

avrdude binary has the wrong date info whereas avrdude.conf has the right date and git commit info

@ndim mentioned the following.

Improve autotool build (part 1/n) #1681 (comment)

@MCUdude and @stefanrueger
Just wondering if you see such issues when using CMake.
1. build failure due `AVRDUDE_FULL_VERSION;`

2. avrdude binary has the wrong date info whereas `avrdude.conf` has the right date and git commit info.
This is consistent with a rogue old src/ac_cfg.h lying around while building in build_$ostype/src.

I am reading up on cmake to add a check for such rogue files, and to fix the sequence of directories the C preprocessor looks for ac_cfg.h. Details in #1706.

mcuee · 2024-02-25T23:38:45Z

I actually mentioned the issue during the testing towards avrdude 7.3 release a few weeks ago.

avrdude 7.3 release discussion #1473 (reply in thread)

BTW, occassionaly I will face the same issue that build.sh will build an avrdude executible with wrong version like avrdude version 7.2-20230720 and then correct avrdude.conf. I need to delete the git repo and redo the build again to fix the issue. Usually this happened under either Windows or macOS. And interestingly the executible is actually correct but just with the wrong version number. The good thing is that avrdude will complain the version mismatch between executible and the config file.

Reference: latest encounter under DragonFLy BSD 6.4.

DragonFly BSD support #1656 (comment)

This adds checks for zombie sourcecode problems, i.e. problems we have tried to eliminate but which might be or have been resurrected. The example check is for the problematic #include "ac_cfg.h" with double quotes instead of <> which were identified as a problem in avrdudes#1706 and then fixed.

mcuee added the bug Something isn't working label Feb 25, 2024

mcuee mentioned this issue Feb 25, 2024

Improve autotool build (part 1/n) #1681

Merged

dl8dtl closed this as completed Feb 25, 2024

ndim mentioned this issue Feb 25, 2024

cmake: for every configure_file, check that the result is not in source dir ndim/avrdude#1

Closed

dl8dtl reopened this Feb 25, 2024

ndim mentioned this issue Feb 25, 2024

Fix cmake build errors related to ac_cfg.h #1707

Merged

stefanrueger closed this as completed in 9616b37 Feb 28, 2024

ndim mentioned this issue Aug 24, 2024

Add checks for zombie sourcecode problems #1910

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

error: use of undeclared identifier 'AVRDUDE_FULL_VERSION' #1706

error: use of undeclared identifier 'AVRDUDE_FULL_VERSION' #1706

dl8dtl commented Feb 25, 2024

dl8dtl commented Feb 25, 2024

dl8dtl commented Feb 25, 2024

mcuee commented Feb 25, 2024 •

edited

Loading

mcuee commented Feb 25, 2024 •

edited

Loading

ndim commented Feb 25, 2024 •

edited

Loading

dl8dtl commented Feb 25, 2024

ndim commented Feb 25, 2024

ndim commented Feb 25, 2024 •

edited

Loading

ndim commented Feb 25, 2024

dl8dtl commented Feb 25, 2024

ndim commented Feb 25, 2024 •

edited

Loading

ndim commented Feb 25, 2024 •

edited

Loading

ndim commented Feb 25, 2024

mcuee commented Feb 25, 2024

mcuee commented Feb 25, 2024

error: use of undeclared identifier 'AVRDUDE_FULL_VERSION' #1706

error: use of undeclared identifier 'AVRDUDE_FULL_VERSION' #1706

Comments

dl8dtl commented Feb 25, 2024

dl8dtl commented Feb 25, 2024

dl8dtl commented Feb 25, 2024

mcuee commented Feb 25, 2024 • edited Loading

mcuee commented Feb 25, 2024 • edited Loading

ndim commented Feb 25, 2024 • edited Loading

How it is supposed to work

What happens on your system?

dl8dtl commented Feb 25, 2024

ndim commented Feb 25, 2024

ndim commented Feb 25, 2024 • edited Loading

ndim commented Feb 25, 2024

dl8dtl commented Feb 25, 2024

ndim commented Feb 25, 2024 • edited Loading

ndim commented Feb 25, 2024 • edited Loading

ndim commented Feb 25, 2024

mcuee commented Feb 25, 2024

mcuee commented Feb 25, 2024

mcuee commented Feb 25, 2024 •

edited

Loading

mcuee commented Feb 25, 2024 •

edited

Loading

ndim commented Feb 25, 2024 •

edited

Loading

ndim commented Feb 25, 2024 •

edited

Loading

ndim commented Feb 25, 2024 •

edited

Loading

ndim commented Feb 25, 2024 •

edited

Loading