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
`connect_sample_db'
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
inside main.
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:
http://tangentsoft.net/mysql++/
?
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.
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:
http://lists.mysql.com/plusplus?unsub=gcdmc-plusplus@xxxxxxxxxxx
|
Try Searching:
servers, voip, java, networking, microsoft ...
|
|
|
| 
