[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