[PD] Espeak external compilation/loading errors on Linux

[Christof Ressi]

> it seems that the espeak.pd_linux is not linked at all against the 
> libespeak library. 
Ha, good catch!

As a side note for other people:

By default, ld doesn't complain about missing symbols during linkage 
when building a shared library, instead you get an error at load time 
(which is what has happened here). You would have to pass 
"-Wl,--no-undefined" to get the error already at link time. However, you 
can't really do that with Pd externals, because they don't actually link 
back to Pd (instead they rely on "-export-dynamic" to get the symbols 
from the host executable itself) and "-Wl,--no-undefined" would give you 
errors for all Pd symbols.

On Windows, however, the linker always tries to resolve all symbols, 
generally by using so called import libraries (although MinGW can also 
directly link against DLLs). If a symbol is not found, you get a linker 
error. That's also why on Windows we need a pd.dll + pd.lib, otherwise 
externals wouldn't have anything they can actually link back to.

Christof

On 13.03.2021 23:04, IOhannes m zmölnig wrote:
> On 3/13/21 10:45 PM, Christof Ressi wrote:
>>>
>> So the actual problem is that Pd can't find the 'espeak' library at 
>> runtime. You obviously have it installed, at least gcc can find the 
>> header files during compilation.
>
> the *actual* problem is, that one (or more) symbol(s) that are 
> supposed to be provided by the libespeak library cannot be resolved.
> there's no error indicating that any library cannot be found at runtime.
>
> i just checked the project and after a successfull compilation, it 
> seems that the espeak.pd_linux is not linked at all against the 
> libespeak library.
>
> this basically indicates a broken build system.
> whenever you happen to meet the author of the makefile, please deliver 
> a good slapping from my side.
>
>
> what is going wrong here, is that modern linkers try aggressively to 
> remove unneeded dependencies. and because libespeak is added to the 
> linker when nothing yet uses any of its symbols, it is discarded.
>
> putting the linker-flags to pull in the libraries after the 
> object-files that require these libraries, fixes the problem:
>
>
> ```
> $ git diff Makefile
> diff --git a/Makefile b/Makefile
> index b3528b2..cd5b0ce 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -63,7 +63,7 @@ TARGETS=$(SOURCES:.c=.$(EXTENSION))
>  pd_linux: $(TARGETS)
>
>  LINUXCFLAGS = -DPD -O2 -funroll-loops -fomit-frame-pointer -fPIC \
> -    -Wall -W -Wshadow -Wstrict-prototypes -Werror \
> +    -Wall -W -Wshadow -Wstrict-prototypes  \
>      -Wno-unused -Wno-parentheses -Wno-switch
>
>  LINUXLDFLAGS =  -export-dynamic -shared  -lc -lm -lespeak
> @@ -71,7 +71,7 @@ LINUXLDFLAGS =  -export-dynamic -shared  -lc -lm 
> -lespeak
>  LINUXINCLUDE =  -I$(PDSRCDIR)
>
>  %.pd_linux: %.c
> -       $(CC) $(LINUXLDFLAGS) $(LINUXCFLAGS) $(LINUXINCLUDE) -o 
> $*.pd_linux $*.c
> +       $(CC) $(LINUXCFLAGS) $(LINUXINCLUDE) -o $*.pd_linux $*.c 
> $(LINUXLDFLAGS)
>         strip --strip-unneeded $*.pd_linux
>
>
> ```
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20210313/d181e440/attachment.htm>