Earl Purple wrote:
> Now I'm back to a debug build with 3.2.1
>
> This won't link:
>
> ${TARGETS}: ${SOURCE}
> ${BUILD} ${INCLUDES} ${SOURCE} ${LIBPATH} ${LIBS} -Wl,-E -o ${TARGETS}
>
> /usr/ccs/bin/ld: illegal option -- E
> usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:V
Bernd Strieder wrote:
> You are doing things that are not guaranteed to work everywhere, that
> are non-standard. And it is more a linker problem.
ok, well strictly C++ has no concept of a library and no such concept
as dlopen().
I do always export objects rather than functions because casting vo
Hello,
Earl Purple wrote:
>
http://groups.google.co.uk/group/gnu.g++.help/browse_frm/thread/5e5ec81ca37129ce/a4843b1eece84a59?hl=en#a4843b1eece84a59
>
> Got it to work back then. Now I have built the libraries in
> 3.4.2-32Bit release mode and the error has recurred.
There have possibly been ch
Anyway, never mind, I solved the original problem... the executable
(even though it exports no symbols of its own) is now linked with this
extra option:
-Wl,-E
Note to anyone else who reads this having had the problem that the
character after the W is a lower-case l (L), not a capital I nor a 1.
even static_cast is failing (compiler error).
error: cannot convert from base `NSP::Builder' to derived type
`NSP::BaseBuilder' via virtual base `NSP::Builder'
(changed from my own namespace name to NSP)
Why?
___
help-gplusplus mailing list
help-gplus
Bernd Strieder wrote:
> Hello,
>
> before we get deeper into guesswork. Does the following help?
>
> http://gcc.gnu.org/faq.html#dso
>
> One should always try to find better answers by others first.
> Google with the request "site:gcc.gnu.org RTTI dynamic" did it.
>
> Bernd Strieder
It helped (th
Hello,
before we get deeper into guesswork. Does the following help?
http://gcc.gnu.org/faq.html#dso
One should always try to find better answers by others first.
Google with the request "site:gcc.gnu.org RTTI dynamic" did it.
Bernd Strieder
___
help
Bernd Strieder wrote:
> Looking at
>
> http://www.isotton.com/howtos/C++-dlopen-mini-HOWTO/C++-dlopen-mini-HOWTO.html
> which tries to provide a portable solution:
I think I saw that around 2 years ago. It is not even accurate. For
example this statement is false:
"Classes
Another problem with t
Hello,
Earl Purple wrote:
> I think this has been addressed before but not for 2 years.
>
> I have a model whereby I dynamically load libraries with dlopen then
> verify that they are the correct types with dynamic_cast.
Just verifying should not be necessary.
>
> dynamic_cast seems to be fai
Ulrich Eckhardt wrote:
> Earl Purple wrote:
> > I have a model whereby I dynamically load libraries with dlopen then
> > verify that they are the correct types with dynamic_cast.
>
> You can't do that. dlsym() returns a void pointer and that is not something
> you can safely use dynamic_cast on. I
Earl Purple wrote:
> I have a model whereby I dynamically load libraries with dlopen then
> verify that they are the correct types with dynamic_cast.
You can't do that. dlsym() returns a void pointer and that is not something
you can safely use dynamic_cast on. If it works, it works because the
ty
Earl Purple wrote:
> I think this has been addressed before but not for 2 years.
>
> I have a model whereby I dynamically load libraries with dlopen then
> verify that they are the correct types with dynamic_cast.
>
> dynamic_cast seems to be failing though with gcc (I am using 3.2.1
> because tha
12 matches
Mail list logo
