Problems with porting alsa-lib: Problems with porting alsa-lib

Problems with porting alsa-lib: Problems with porting alsa-lib

Problems with porting alsa-lib

Linux audio alsa lib VERSIONED_SYMBOLS

During the migration of alsa lib in the past two days, I encountered a problem and was stuck for a long time.
Make a record and be trapped by the same problem later.

The problem is that there is a project where the customer requests to use the new alsa-lib library.
Go to the alsa official website and check out the latest version 1.0.28.
Since we can use a new one, we will satisfy our customers and use the latest one.

Next, let's take a look at the problem.
In fact, the project also used the alsa lib library before. After all, alsa is the audio architecture widely used in linux systems.
Porting is actually not troublesome.
First, let's get the code.
Then execute configure to generate a heap of items. The most important one is the config. h file.
Generally, in linux, the application or application layer library file is followed by make and make install.
Because our system has our own make script, these two steps are replaced by our own make command.

The first problem is:
Externals/alsa-lib/src/alisp. c: In function 'obj _ type_str ':
Externals/alsa-lib/src/alisp. c: 1028: 1: error: control reaches end of non-void function [-Werror = return-type]
The error message shows that this is a function of non-void type and has no return value.
However, we can see from [-Werror = return-type] that this is actually a warning, but it is treated as an error.
Why is it treated as error?-Werror = return-type is configured.
In locl compile flag, add-Wno-error = return-type to solve the problem.

The above problem was quickly eliminated. I am not charged for the problem below.
Question:
/Ld: failed to set dynamic section sizes: Bad value
Compilation is my weakness. As soon as the compilation problem occurs, I feel helpless.
In fact, all fruits have their own causes. No errors for no reason.
I checked the compiled log before error and found no useful information.
Next, ask du Niang for help.
Someone has encountered a similar problem. The solution to this problem is that a function is declared but not defined in the Code, which causes this problem. In addition, the function definition is added, solve the problem.
The alsa lib code is not written by me. I do not know whether the declared but undefined functions exist.
The amount of code in the alsa lib library is also considerable. You can only think about it after checking it again.

Check the compilation log and find that many warnings are prompted for repeated macro definitions at the beginning.
Use # ifndef to resolve these warnings.
Compilation still has the same problem.

Some function parameters in the compiled log are not used in the warning. After finding these functions, I found that no function is defined for function implementation (corresponding to the preceding online solution ).

Is there a problem because some parameters are not specified during configure?
I searched other people's transplant cases online and found no inconsistency with my configuration.

Since an important function of configure is to generate a config. h file, compare the newly generated config. h file with the config. h file in workable version.
Comparison shows that there are many differences.
Replace it with the old config. h.
Make, passed !!!
It must be a problem with config. h.

By class-by-class exclusion, the new config. h contains the following definitions:
/* Compiled with versioned symbols */
# Define VERSIONED_SYMBOLS /**/
Delete the definition and compile it.
Search for the macro with Baidu and find that someone has encountered the same problem (du niang still has two sub-accounts ):
Http://www.android100.org/html/201409/16/65158.html
When you see this definition, there is a prompt before you think of a compilation error:
Libasound. so: version node not found for symbol snd_ctl_elem_info_get_dimension @ ALSA_0.9.3

However, du Niang has only two children.
To learn more about VERSIONED_SYMBOLS, Google is the best choice.
Http://infocenter.arm.com/help/index.jsp? Topic =/com.arm.doc. dui0204.7/Beijfhhg.html

You can add specially-named symbols to input objects that cause the linker to create symbol versions. These symbols are of the form:
Name @ version for a non-default version of a symbol
Name @ version for a default version of a symbol.

You must define these symbols, at the address of the function or data, as that you want to export. the symbol name is divided into two parts, a symbol name and a version definition version. the name is added to the dynamic symbol table and becomes part of the interface to the shared object. version creates a version called ver if it does not already exist and associates name with the version called ver.

For more information on how to create version symbols, see:
Adding symbol versions in the Compiler User Guide
Chapter 2 Writing ARM Assembly Language in the author er Guide.

Example 4.6 places the symbols foo @ ver1, foo @ ver2, andbar @ ver1 into the object symbol table:

Example 4.6. Creating versioned symbols, embedded symbols

Int old_function (void) _ asm _ ("foo @ ver1 ");
Int new_function (void) _ asm _ ("foo @ ver2 ");
Int other_function (void) _ asm _ ("bar @ ver1 ");

 

The linker reads these symbols and creates version definitions ver1 and ver2. The symbol foo is associated with a non-default version of ver1, and with a default version of ver2. The symbol bar is associated with a default version of ver1.

It is estimated that foo @ ver1 AND foo @ ver2 are not defined in alsa lib, so the preceding error occurs.

The solution is to delete:
# Define VERSIONED_SYMBOLS

There is no way to create associations between versions with this method.

 

Newlib porting

First, try to directly modify the configuration and compile it. If there is an appropriate configuration, this is of course the most convenient.
If there is a problem, consider completely porting it.
 
Problems encountered during Linux kernel porting and compilation

The cause of the error is that there is no cross-compiler arm-linux-gcc. This cross-compiler is based on gcc. Generally, gcc of Version 4.1 is used. This version does not have such high syntax requirements and does not cause frequent compilation errors, the specific production process of the cross compiler is unclear. There is a lot of information on the network. You can find it by yourself.