You're right, I'm guilty of a horrible case of misreading and
misremembering. I apologize. I did have to tinker with the Makefile but
that was to tell it the proper location of the already compiled library.
However, going back a little...
> custom1.cc:31: error: ISO C++ prohíbe la declaración de
> sin tipo
that's a direct result of
> custom1.cc:28: error: error sintáctico before `int'
since the declaration for the function didn't work, it's no longer
I suspect that's a direct result of
> custom1.cc:17:31: la macro "sql_create_5" recibió 14 argumentos, pero
> solamente tomó 13
Which, as you said, shouldn't be happening; why does it think
sql_create_5 requires 14 arguments? 13 is the right number unless
somehow the macro got redefined/overwritten somewhere. In any case, this
is clearly (at least, from the available data) the problem.
This one's shooting kind of wildly in the dark, but is it possible that
one of the names being used in that macro is overridden by some other
macro that's used in the internationalization process?
Warren Young wrote:
> Earl Miles wrote:
>> The binary RPM contains the <strstream> <ssstream> patch, whereas
>> ../sqlplusint does not.
> Are you talking about the binary RPM here:
> Those are built straight from the official source tarball on that page.
> There has not yet been a strstream -> stringstream change in the
> official source tree.
>> On my RedHat 9 system, I was able to fix this by changing the Makefile
>> to use /usr/include/mysql++ I think.
> That has nothing to do with this issue. Yes, my RPMs put the include
> files there, but that doesn't affect someone's ability to build the
> examples within the tarball. As I said, they don't use the headers and
> libraries from the RPM, they use the ones in ../sqlplusint.