Re: [Hamlib-developer] libltdl / FT747GX timeout problem - solved?

[Stephane F. <f8...@fr...>]

Kamal Mostafa skribis:
> Stephane Fillod wrote:
> > Looks like there's a problem with the embedded libltdl.
> > [...] can you install libltdl-dev ?
> 
> Chris Bryant skribis:
> > Ok Stephane, that fixed it, thanks. I'm using debian unstable here, to be sure 
> 
> Stephane Fillod wrote:
> > Thanks for confirming the libltdl-dev issue. On a side note, that means we have
> > to fix that problem before thinking of releasing hamlib 1.2.11.
> 
> Chris Bryant wrote: 
> > Btw I didn't have that probelm building 1.2.10 from source (d/l from the 
> > sourceforge d/l page)
> 
> 
> Sorry I'm arriving late to the party here folks...
> 
> I suspect that this libltdl problem is related to the change I made on
> 2010-03-01 (r2841) which affected the way hamlib selects which libltdl
> to use:
> http://sourceforge.net/mailarchive/message.php?msg_name=1267470158.7216.21.camel%40fourier

Kamal, I still think you did the right thing with the libltdl update.
However, I don't understand why the order was changed in Makefile.am
in the definition of SUBDIRS:

-SUBDIRS = macros include lib libltdl src @BACKEND_LIST@ @ROT_BACKEND_LIST@ \
+SUBDIRS = macros include lib src $(subdirs) @BACKEND_LIST@ @ROT_BACKEND_LIST@ \

According to me, 'src' should be built after $(subdirs), since src
depends on libltdl, when selected. Do you agree?

SUBDIRS = macros include lib $(subdirs) src @BACKEND_LIST@ @ROT_BACKEND_LIST@ \

> At that time, the group discussed (but decided against) the idea of
> removing the bundled libltdl from hamlib altogether, which would force
> users to want to build hamlib from source to use their distro's native
> libltdl (or build that too if their distro doesn't provide it).  FWIW,
> it sounds like Chris' problem may have been avoided if we had taken that
> step.

Actually, I'm not sure what was Chris' problem. Probably, it's more like
me guessing it's because of libltdl-dev, while in fact the configure script
was too slow finding the python dev setup.
The "find /usr ..." is not that smart in macros/python.m4, and probably
has to be reworked, maybe with a more up to date script.

> The group may want to consider the idea of dropping the bundled libltdl
> again.  I'm not sure how many hamlib users even "need" it anymore (I
> think libltdl is probably supplied by most distros), but we do have
> evidence that its presence causes some problems: CVE-2009-3736, and now
> Chris' problem.  Is the benefit of bundling libltdl worth the burden
> that it imposes on hamlib?

Yes, it is worth it because some non-Linux distos are frugal, or carry
broken library. For example, the cross-compilation for win32 under Linux
does need the bundled libtldl.

73
-- 
Stephane - F8CFE