Re: [Hamlib-developer] A proposal for a Hamlib++

[<rem...@gm...>]

Hi Robert,

Thanks for your email and for your work.

I make this conversation open to anyone because others might be 
interested. This is an open-source project after all.

Several remarks and ideas:

* When I started to use MXE, I insisted that only Hamlib3 worked out of 
the box. (Hamlib 1.x made libltdl problems) I could build fldigi without 
serious difficulty. This is why I suggested to use it. I would have been 
happy to help, instead of seeing hamlib removed.

* I understand that MacOS with Hamlib makes problems, but MacOS makes 
about 5% of fldigi users maximum. Hard to believe that 95% of users must 
suffer for Macintoshes.

* There is a fldigi configure option which completely avoids Hamlib. It 
would have been a simple choice for Windows and OsMac users.

* I understand that token_t is also defined in MacIntosh, but again it 
is 3% of users; and it is perfectly possible to make a version of Hamlib 
where this type is renamed. Indeed, the Hamlib development team should 
react immediately to fix this problem. But if we were stuck, we could 
have our own temporary version of hamlib. After all, this was done with 
xmlrpc_c during years, because this library is not supported at all 
(This is why I removed it). Please see the wiki, xmlrpc_c had to be 
deeply patched. So why not doing that temporarily with Hamlib ?

You and Dave have taken the decision to remove Hamlib, and I am not 
convinced by the reasons you give. Naively, this is not what I expect 
from an open-source development team, but I respect your choice, and 
wish you good luck and much fun!

Remi




Le 21.06.2013 16:59, Robert Stiles a écrit :
> Remi,
> The three issues that precipitated this event are (at least on my side):
>
> MacOSX libltdl is broken when searching for dynamic libs in non standard
> places, The attached patch allow me to search directly for the .so files.
>
> Setting ALL environment variable related to Library search fails on the
> Macintosh. Because libltdl is renaming the file extensions from the load
> path to .dylib. Which is what you want in most cases, but not in our
> case. The initial assigned search path is unaltered by libltdl.
>
> The token_t variable used in hamlib is in conflict with system header
> files on the Macintosh since version 10.7. Changing all of the token_t
> variables to r_token_t in hamlib would fix this issue.
>
> I have made it work on the macintosh when the DLL and .so file are
> stored in the Application bundle by #ifdef the system header files , and
> apply the patch to register.c file.
>
> So far I'm unable to create DLL using MXE on the windows side. The build
> system is messing withlibltdl creation.
>
> Since we have to use DLL's (current hamlib) I'm currently unable to
> create a windows version.
>
> Robert
>
> ------------------------------------------------------------------------
> *From:* Nate Bargmann <n0...@n0...>
> *To:* "rem...@gm..." <rem...@gm...>
> *Cc:* w1hkj <w1...@be...>; Stephane Fillod <f8...@fr...>;
> Kamal Mostafa <ka...@wh...>; Robert Stiles <kk...@ya...>
> *Sent:* Thursday, June 20, 2013 9:04 PM
> *Subject:* Re: A proposal for a Hamlib++
>
> * On 2013 20 Jun 16:49 -0500, rem...@gm...
> <mailto:rem...@gm...> wrote:
>  > Oh, big change.
>  >
>  > Sorry for that, but I am not interested to work this way on this project.
>
> Hi Remi.
>
> As always, your efforts for both Hamlib and Fldigi have been appreciated.
> Please don't end your work with either project. This was a technical
> problem that we have been unable to resolve. Dave's decision is based
> on the technical merits of the issue and I respect that. There are no
> hard feelings on my part, so everyone please continue to write good
> software that benefits the amateur radio community.
>
> 73, de Nate >>
>
> --
>
> "The optimist proclaims that we live in the best of all
> possible worlds. The pessimist fears this is true."
>
> Ham radio, Linux, bikes, and more: http://www.n0nb.us <http://www.n0nb.us/>
>
>