Now CMake will build both static and shared libs

[subnut]

Closes #952

• https://stackoverflow.com/a/29824424
• http://developer.intra2net.com/git/?p=libftdi;a=blob;f=src/CMakeLists.txt;h=17b36173621bd9337b03e07a56f468d598ac208b;hb=HEAD#l41

[mcuee]

Tested to be good under Ubuntu 20.04 x64.

[dl8dtl]

Alas, it doesn't build for Windows and MacOS - see logfiles above.

[mcuee]

The current shared build under Windows is broken anyway. This pull request does not sorted out the issue.
Ref:

• Windows shared library build problem under both VS2019 and MSYS2 #954

[subnut]

I don't have a windows machine nearby. Can somebody check why the msvc build is failing?

[dl8dtl]

I don't have a windows machine nearby. Can somebody check why the msvc build is failing?

See the CI toolchain builds.
But seems you got it to work for MacOS already, great!

[subnut]

But seems you got it to work for MacOS already, great!

Well... I didn't actually get it to work. I just worked around it 😅

It looks like macOS dynlib, like Windows's DLL, doesn't like undefined references. So, I simply disabled the dynamic (shared) library building for both Windows and macOS.

Once #954 is fixed, I guess macOS shared library shall also work 🤷
I dunno. Never have I ever seen a mac in real life, let alone use one.

See the CI toolchain builds.

I did, and it looks like some dependencies (libelf, libftdi, etc) aren't being built. Dunno why though.

[mcuee]

The current Windows CI VS build is very special (unlike any CMake based projects I know of).

But I think there should be a way to get the macOS build right. FYI libftdi CMake build (with both static and shared library) works for macOS.

Edit: this may not be correct as it may well be in the same situation as Windows.

[mcuee]

It looks like macOS dynlib, like Windows's DLL, doesn't like undefined references. So, I simply disabled the dynamic (shared) library building for both Windows and macOS.

Once #954 is fixed, I guess macOS shared library shall also work 🤷 I dunno. Never have I ever seen a mac in real life, let alone use one.

Indeed. The error message seems to be very much similar to Windows if I enable shared build under macOS using your patch.

mcuee@mcuees-Mac-mini build % make -i
Consolidate compiler generated dependencies of target objlib
[ 90%] Built target objlib
[ 91%] Built target staticlib
[ 93%] Linking C shared library libavrdude.dylib
Undefined symbols for architecture arm64:
  "_avrdude_message", referenced from:
      _arduino_read_sig_bytes in arduino.c.o
      _avr_tpi_chip_erase in avr.c.o
      _avr_tpi_program_enable in avr.c.o
      _avr_read_byte_default in avr.c.o
      _avr_read in avr.c.o
      _avr_write_page in avr.c.o
      _avr_write_byte_default in avr.c.o
      ...
  "_ovsigck", referenced from:
      _avr910_initialize in avr910.c.o
      _flip1_initialize in flip1.c.o
      _flip2_initialize in flip2.c.o
      _ft245r_initialize in ft245r.c.o
      _jtagmkII_initialize32 in jtagmkII.c.o
      _jtag3_initialize in jtag3.c.o
      _serialupdi_chip_erase in serialupdi.c.o
      ...
  "_progbuf", referenced from:
      _avr_write in avr.c.o
      _avr_verify in avr.c.o
      _fileio in fileio.c.o
      _flip1_initialize in flip1.c.o
      _flip1_read_memory in flip1.c.o
      _flip2_initialize in flip2.c.o
      _ft245r_open in ft245r.c.o
      ...
  "_progname", referenced from:
      _arduino_read_sig_bytes in arduino.c.o
      _avr_read_byte_default in avr.c.o
      _avr_read in avr.c.o
      _avr_write_page in avr.c.o
      _avr_write_byte_default in avr.c.o
      _avr_write in avr.c.o
      _avr_signature in avr.c.o
      ...
  "_quell_progress", referenced from:
      _fileio in fileio.c.o
      _stk500v2_command in stk500v2.c.o
      _check_retries in usbtiny.c.o
      _do_op in update.c.o
  "_verbose", referenced from:
      _avrftdi_log in avrftdi.c.o
      _avrftdi_pin_setup in avrftdi.c.o
      _avrftdi_flash_write in avrftdi.c.o
      _avrftdi_lext in avrftdi.c.o
      _avrftdi_flash_read in avrftdi.c.o
      _bitbang_cmd in bitbang.c.o
      _bitbang_cmd_tpi in bitbang.c.o
      ...
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
[ 93%] Built target sharedlib
[ 95%] Building C object src/CMakeFiles/avrdude.dir/main.c.o
[ 96%] Building C object src/CMakeFiles/avrdude.dir/term.c.o
[ 98%] Building C object src/CMakeFiles/avrdude.dir/whereami.c.o
make[2]: *** No rule to make target `src/libavrdude.1.0.0.dylib', needed by `src/avrdude'.  Stop.
[100%] Built target avrdude

[dl8dtl]

if I enable shared build under macOS using your patch

However, note that the classic autoconf/automake approach had no problems creating a shared lib under MacOS.

I've posted the different linker commands here:

#954 (comment)

[dl8dtl]

Regarding Windows DLLs, I see DLLimport and DLLexport in the Microsoft docs. That ought to be able to solve the WinAPI issue, I think.

[mcuee]

if I enable shared build under macOS using your patch

However, note that the classic autoconf/automake approach had no problems creating a shared lib under MacOS.

I've posted the different linker commands here:

#954 (comment)

That is a good point. Indeed I have no issues to build the shared lib under macOS (once I use the correct ./configure) using the release auto-tool tarball. So probably there is a easier way out for macOS compared to Windows.

[subnut]

This. This is why autotools doesn't complain but CMake does

-Wl,-undefined
-Wl,dynamic_lookup

[mcuee]

Now the error messages of macOS build and Windows build are the same with the latest version (commit 439f695).

[subnut]

I'm closing this PR for now.

Might come back later when I have more time to invest on this.

[subnut]

This PR has been succeeded by #960, because GitHub doesn't allow me to re-open this PR.