gingerbread issue with undefined reference for ld
Recently I tried to add a new dynamic library (.so file) in the gingerbread source. The library seems to be properly copied to the respective folder, also there was no compilation error.
But at the end moment in linking, the build failed saying.
target SharedLib: libcameraservice (out/target/product/sholes/obj/SHARED_LIBRARIES/lib*_intermediates/LINKED/
y.so)
prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm-eabi/4.4.3/../../../../arm-eabi/bin/ld: out/target/product/sholes/obj/SHARED_LIBRARIES/lib*_intermediates/z.o: in function w.cpp:109: error: undefined reference to
We can easily know that the symbols are not found in the respective linked library, but hey wait a second, we said the library is properly copied and it’s in LINKED library path. What is the problem?
The difficult the question, but the simple was the answer. The library I was linking was a c .so file, but where I was linking it was a cpp .so file. Umm .. extern “C” { } saved me 
Concepts of Reference Counting
http://www.codeproject.com/KB/cpp/rcptr.aspx
In your introduction you imply that in an implementation for reference counting the object always holds the reference counter (in your example by inheritance). This is but one possible implementation of a reference counting concept however.
A reference counter does not need to be part of an object (or a base class), and the object doesn’t even need to know about it for all it cares. The solution you provide does that. This is an approach called ‘intrusive reference counting’ because you need to ‘intrude’ on each type of object definition that you want reference counting implemented for. It is sensible to do this for an OO design when the object itself ‘knows’ that the added storage and function call levels implied cost less than the off-chance of someone accidentally forgetting to release memory, or if you don’t simply care about performance cost. If you build an application from scratch, it is perfectly reasonable to do this.
Other implementations of reference counting create specialized types of pointers (‘smart pointers’) that collectively own the reference counter object (usually just a standalone int), and destroy that object upon decrementation to 0. This is preferable in old code that you do not want to touch or when you are referencing third-party objects whose class declarations you cannot change to inherit from some base class. boost:shared_ptr implements this concept, and you can also find an almost complete example in Bjarne Stroustrup’s “The C++ Programming Language”. The disadvantage of this concept is that each smart pointer needs to hold two pointers – one to the object they point to and one to the collectively shared reference counter. It is also neccessary for the application that use these smart pointers to be aware of that fact, since they explicitely need to use the appropriate smart pointer types and may never call delete on them (which is about the only thing that ultimately distinguishes them from ‘normal’ pointers). Note that the auto_ptr type is a rather incomplete implementation of smart pointers.
Yet another approach is that you implement a memory manager that holds reference counters. I consider this the ‘most object-oriented’ approach because reference counting is really the job of a memory manager. It does afford having your own memory manager though, and most applications don’t bother with that.
I did implement this last concept in my own Pool memory manager: in this implementation the memory block object also holds a corresponding block of ‘use counters’ (which are in fact reference counters), so there is no need to individually destroy reference counter objects as they’re being destroyed along with the blocks that hold the memory for the objects being managed by the pool. The memory manager also returns it’s own specialized smart pointers.
Just wanting to give you some insight on various possible solutions. There are more, and the boost library offers quite a few variants if you’re interested.
~Stefan63/www.codeproject.com
Audio tools for your rescue
It’s quite a necessary to check the output buffer before delivering it to kernel/hardware device. Generally, it’s a good idea to write all the sound buffer into a file before delivering to audio framework (for example ALSA) and copy that file and play it in PC. How can we play a raw data given to ALSA?
There is a really good tool out there in the market called GoldWave. It helps to play raw PCM, ISDN, ASCI data with respective bits and bit order of little and big endian.
Debugging a crahsed process in Android~~
Many times it has happened to me that the process is crashing and there is not a single clue from the ddms log to go ahead. Then the kernel debugging comes to the resort to thrash out the frustration.
Audio/Surface flingers, media server, service manager are the common place for such a nasty issue. dmesg and strace are really good tools to debug such an issue.
dmesg prints the message buffer of the kernel. It has the list of diagnostic messages about what’s going on in the kernel if the user process does something wrong or something happens to the device drivers. It also contains the exception and faults of the system.
I first run the dmesg and check the last timed message before executing the problematic process. This is just to make it easy to look at the right place after the process is crashed.
strace is an awesome tool to have a detailed information about what a process is doing in the execution. What are the files being accessed, the system calls, forked processes and so on.
I usually run the following command to trace the process from the adb shell
1. strace -ff -F -tt -s 200 -o /tmp/strace process-bin-path(/system/bin/mediaserver)
-ff > follow fork
-F > follow vfork
-tt > print time in micro seconds
-s > buffer size of printing the message
-o > file to generate the strace output
Last is bin process full path, or you can use -p with process id. -p option can be used for Java application. (Use ps command to show running processes)
Analyze the strace and dmesg output to solve an issue in a snap ^^
ALSA tutorial
This really amazing tutorial for ALSA API.
It’s not only related to APIs, but also gives a basic audio mechanism.
Platform drivers @ Linux
What the heck it is!!!!
Linux Kernel 2.6 introduced us the unified driver model. In PC based environment, the devices are connected to different kind of buses like PCI, ISA etc. When a device is connected to a bus, it receives a unique identification which will be used for further communication with the CPU. The driver for the related device can be initialized/removed using the probe/remove method normally.
What about the embedded system? Mobile phones?
Mobile phones usually don’t have a sophisticated bus mechanism found in PC systems. So there must be a way to attach a device to the embedded system like Memory, input MIC, accelerometer etc.
The answer is Platform Drivers. They are similar to normal drivers, but the major difference is their working mechanism. They help the devices directly connect to CPU. The driver can be identified using the unique name within the system and it can be configured for interrupt.
A platform driver should be register and unregister using platform_driver_register() and platform_driver_unregister(). The machine file for a particular board can maintain an array of devices connected to CPU and add them using platform_add_devices().
When platform_add_devices() is called, it internally calls probe() function of each of the driver which helps the driver to initialize.
OpenCore PV logging
Filed under: Android | Tags: Android, Opencore, Packet Video
Leave a Comment After searching a lot over the Internet to capture the logs for Packet Video Multimedia framework, the following things are concluded, though I am still not able to capture the log in pvlogger.txt file.
Most of the people mentioned to compile with ENABLE_PV_LOGGING=1 option compilation for Android platform with /sdcard/pvlogger.txt. It was also mentioned to write [Log Level] [Node to log] in the pvlogger.txt. Under the heaven, I was still clueless to see a single log.
The most important part of source exists in external\opencore\android\thread_init.cpp, where it checks PVLOGGER_INST_LEVEL and then includes android_logger_config.h which has the logger class. Therefore, add “#define PVLOGGER_INST_LEVEL 5″ in this file and create pvlogger.txt file with 8 in it. You can see the log. Enjoy!!
Android’s system, data and cache images
When the Android platform is compiled, it generally creates .img files for system, data and cache.
It happens that in the phone these images are not directly downloaded directly, but the phone flash memories are formatted in different kind of file system i.e YAFFFS, RFS, XSR. It seems RFS, XSR are proprietary file systems, but there is TinyBML which is open source and present in Boot loader as well in the Kernel.
So these .img images must be converted to the compatible file system format and then it should be downloaded.
Android src compiling process
It’s first of Android kind though not a basic step for Android.
Android build system is quite clean and easy to understand, but there is an obvious dependency to compile platform source and Kernel source.
The OEM usually keeps their code including init.rc in the vendor directory. So when we compile the platform source, the product specific directory is created with root and system directory.
The root directory has init.rc which must be used in the ramdisk image in order to execute it when the root file system is mounted.
Because of this obvious dependency, we usually compile platform, kernel and boot in that order.
Hello again!!
I have been off from the blogging for quite a long time and I feel the need to wake myself from hibernation and start the purposeful course.
There have been many events happened and the things have been changed. The most big transition has been to go into the Android field. There was a sudden deep into the Android last year because of the global demand for smart phones and people’s openness to accept the Google’s new platform. I would like to blog additionally for “the android” about the knowledge, opinions, tips etc. And, of course, the photography!!!
So see you soon~~
