Search code examples
autotoolsyoctoautoconfbuildroot

How can a build environment introduce new LDFLAGS into an autoconfig build


I am building the same library (TI GBM) in two different build environments (buildroot and Yocto). The binaries from Yocto work, but the binaries from buildroot fail due to a segmentation fault. I compared the makefiles generated by autoconfig in the two build systems and noticed differences in the LDFLAGS.

Yocto:

LDFLAGS =  -L/home/kyle/gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/lib -Wl,-rpath-link,/home/kyle/gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/lib -Wl,-O1 -Wl,--hash-style=gnu

Buildroot:

LDFLAGS = 

How is Yocto adding these new linker directives to the makefile?


Solution

  • How is Yocto adding these new linker directives to the makefile?

    Yocto is not actively doing anything -- it is the configure script that does the work. Its whole purpose is to analyze the system on which it runs to identify required tools, figure out appropriate flags, and determine the presence or absence of various system facilities. Having done so, it (generally) creates one or more Makefiles for you by filling in templates included with the program source. One of the things it fills in is a value for the LDFLAGS variable.

    How configure chooses the flags it does depends in part on how it is written, and in part on how it is run. You can specify some variables on the configure command line or via its environment, and you can affect others via command-line options. Some of these can have a cascading effect. For example, the particular choice of LDFLAGS in your yocto environment is likely related to the C or C++ compiler that was chosen.