Rafa,
Ojo que el problema es solo con la versión en desarrollo de Harbour en el SVN. No afecta a xharbour.
El problema es que han tenido la "maravillosa" idea de cambiar la forma de trabajar de las funciones del extend system:
Antes teniamos las functiones hb_par...() y las funciones hb_stor...() que permitian uno ó más parámetros. Es decir, por ejemplo hb_parc() estaba prototipada asi:
char * hb_parc( int, ... );
significando "..." un parametro opcional, que podiamos ó no usar. Ahora hb_parc() es distinta!
char * hb_parc( int );
y si necesitas acceder a un valor de un array, obteniéndolo como cadena, ahora hay que llamar a otra función:
char * hb_parvc( int, ... );
Resumiendo: hb_parvc() es ahora el equivalente del antiguo hb_parc(), y hb_parc() es distinto. Esto, y disculpen mi expresión, es una gran "cagada". Tendrian que haber dejado esas funciones como estaban y añadir funciones con nueva funcionalidad. De la misma forma que Windows cuando mejora una función del API de Windows le añade "Ex", asi existen CreateWindow() y CreateWindowEx(). Pero ni se les pasa por la cabeza cambiar CreateWindow() y romper compatibilidad con el código existente.
Esto hace que librerias de terceros que contengan módulos en C, darán GPF! con el nuevo Harbour. Y que obligue a recompilarlas todas. Bravo por Przemek y Vikthor
Asi que ahora hay dos opciones, o que ellos rectifiquen (cosa que dudo porque son unos cabezotas) ó que tengamos que adaptarnos a esto. Nosotros hemos optado por probar a convertir todas las llamadas a funciones hb_par... y hb_stor... en llamadas a hb_parv...() y hb_storv...() y que ocurre con versiones antiguas de Harbour y con el xHarbour actual (porque de paso han roto la compatibilidad con xHarbour!) ? Pues que tenemos que proporcionar una capa de funciones hb_parv...() y hb_storv...() que no existen.
En fin, tomémoslo con filosofia, pero si pasan por la lista de desarrollo de Harbour, no se olviden de "felicitar" a Przemek y a Vikthor por estas decisiones de diseño tan "acertadas"