[uClibc] Re: uClibc++ update
Garrett Kajmowicz
gkajmowi at tbaytel.net
Tue Sep 7 22:38:03 UTC 2004
I would like to start off by thanking for all of the time that you have put
into this. I know that it can't be fun trying to work with code which (for
you, at least) doesn't want to work.
> include/ios:219:error: invalid conversion from `int' to `void*'
> probably * is superfluos
Tha call must return a pointer, either null/0 or non-null/zero. I thought I
could return any integers as a pointer (in this case 1), but I guess I can't.
Future code will simple return this.
>
> After this change tried to build asm5900-20020415-mfx5 (from
> http://upx.sf.net/download/tools ), assemble.cpp fails.
>
> Now I took my favorite c++ test build, upx-1.92-cvs
I will start using that as a test application. I'm installing some of the
base libraries now.
> If I do not import the libsupc++.a file, then it fails with many errors,
> but if I added it to the included libs at link time, it builds correctly.
> For this case a libuClibc++.la file would be proper to have (so that
> libsupc++ is included all the time)
The compiler wrapper script is supposed to determine wether or not -lsupc++
needs to be added to the library list when you build the library. I do not
know much about .la files (in fact, I know nothing about them) so I will have
to do some research before that happens.
> If I import the libsupc++.a file it should be fully added to the shared
> lib (why is it not added to the libuClibc++.a too?), it fails w/:
> msg.o undefined reference to __cxa_bad_typeid
> work.o undefined reference to vtable for __cxxabiv1::__pointer_type_info
libuClibc++.a is currently for testing only - it should not install itself
automatically. I'm looking at supporting that, but I'm not certain of all of
the ramifications.
> if I add again libsupc++.a manually at link time, it builds correctly.
>
> I have looked into libsupc++.a, these are there, but they are not in
> libuClibc++.so (although some parts from libsupc++.a where added).
>
> libsupc++.a is only partly added to the lib for some reason, so it is no
> use to add it to the c++ lib, better using it separately for now (through
> an .la file or .so linker script), that could also add -lgcc_s -lc)
>
> I am not sure if uClibc supports .la files, an so linker script is
> tested and works w/ uClibc (but this procedure will create bigger
> executables due to libsupc++.a usage)
Hense the reason I want to avoid static libraries and the requirements to use
them. I will do more testing with no importing, however, in an attempt to
make life easier for all.
> Attached are the used patches.
>
> Proposals:
> 1. if IMPORT_LIBSUP is set g++ -print-file-name=libsupc++.a could be
> used to set some default, it prints the full path of the file if found
I will check it out and do so.
> 2. LDFLAGS is not used at link time of the library
I will fix that.
> 3. include/Makefile is superfluos (removed already the references in
> patch)
I like the idea of having that there in the event that I need to do something
later - it doesn't cause any harm.
In regards to your more recent e-mail, I am not certain why you are
experiencing the problems that you are. It sounds like a linker problem to
me, but I will look at it nonetheless to see if I can duplicate it.
- Garrett Kajmowicz
More information about the uClibc
mailing list