shared libs, where art thou?

[HASM]

Building a fresh clone of fltk master from github, passing --enable-shared to ./configure.

Any reason the shared libraries are created under ./src and not under ./lib?

-- Henrique

[Ian MacArthur]

On 6 Mar 2023, at 15:35, HASM wrote:
>
> Building a fresh clone of fltk master from github, passing --enable-shared to ./configure.
>
> Any reason the shared libraries are created under ./src and not under ./lib?

It’s historical... I don’t think it makes sense either but it has been so for a long time.

Also (for the Win32 case) the DLL’s probably need to be in the same folder as the binaries, so just moving them to ./lib isn’t necessarily the “universal” solution either...

[HASM]

>> Any reason the shared libraries are created under ./src and not under ./lib?
> It’s historical...

Good, valid reason.

> Also (for the Win32 case) the DLL’s probably need to be in the same folder as the binaries,

Cmake is so fricking complicated but there has to be some way of putting them "in the right place™" depending on OS/architecture:-)

I was (still am) struggling to convince tigervnc's cmake to look into my fltk git clone, rather than the installed version, and this make it seem that I need to tell the linker to look into two places.

-- HASM

[Albrecht Schlosser]

On 3/6/23 16:35 HASM wrote:
> Building a fresh clone of fltk master from github, passing
--enable-shared to ./configure.

Which OS, and which shell? (Windows, MSYS2, ...)

> Any reason the shared libraries are created under ./src and not under
./lib?

Probably history.

One reason might be the Windows problem that both the shared library
stub archives and the static libraries have the same file type '.lib'
which is a known and annoying issue causing problems in many contexts
(particularly if someone - i.e. a library build system - tries to work
around this and "invents" other naming conventions!).

Maybe we could build the shared libs in ./lib where *I* would expect
them. This is done in CMake builds, BTW. However, we need to take care
of the Windows naming issues mentioned above which exist also if you
build with configure/make under MinGW/msys etc..

[Albrecht Schlosser]

On 3/6/23 20:33 HASM wrote:

[Ian wrote]

Also (for the Win32 case) the DLL’s probably need to be in the same folder as the binaries, 

This is only needed when you execute the binaries, or the DLL's have to be in your PATH, or (in Linux or MinGW/MSYS2) you can define the DLL path in the environment variable LD_LIBRARY_PATH, e.g.

$ LD_LIBRARY_PATH=/path/to/fltk-1.4/src ./my_program

Cmake is so fricking complicated but there has to be some way of putting them "in the right place™" depending on OS/architecture:-)

No matter where the libs are built, if you install the libs they should be installed in an appropriate place, relative to your CMAKE_INSTALL_PREFIX.

However, you can build and run your own projects using the FLTK build directory as well.

I was (still am) struggling to convince tigervnc's cmake to look into my fltk git clone, rather than the installed version, and this make it seem that I need to tell the linker to look into two places.

Please take a look at our README.CMake.txt in chapter 3 "Using CMake with FLTK". I know that I built tigervnc using the same technique as described there (I had to edit the tigervnc CMake file slightly though). The key is to define FLTK_DIR as described when you first run CMake to generate the build files. I can't tell you more off the top of my head, but I can try it probably tomorrow.

HTH,
Albrecht