2

I'm trying to get libtool and yasm to work together.

yasm creates the correct .o files from my .asm sources, but I can't figure out how to get libtool to build the associated .lo and .dep files. It wants to build the shared library, incorporating the .o files.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Keith Bostic
  • 21
  • 2

2 Answers2

0

libtool generated files typically use the following layout: The .lo file in a build directory consisting of location metadata; the static object .o files in the build directory; and the PIC / shared .o objects in the build/.libs directory.

You can use the libtool compile mode. I'm not familiar with yasm, so you'll have to fill in the switches. It will run the yasm build twice, once with -DPIC (and maybe other shared object options).

libtool --tag=CC --mode=compile yasm <options> src.asm

If using automake, this may require an explicit rule for the .asm files:

.asm.lo:
        $(LIBTOOL) --tag=CC --mode=compile \
        yasm <options> $<

Keep in mind that those are TABs in Makefiles, not (8) space characters! You might also need to add: .SUFFIXES: .asm .lo prior to this. I use the variable $(LIBTOOL), because some platforms (OSX for example) need to install it as glibtool, and it's what Makefile.indoes.

The generated src.lo, src.o, .libs/src.o should be respected by make clean for example.

For your library libfoo, you will need to let automake know about these sources with: EXTRA_libfoo_la_SOURCES = src.asm, and obj deps with libfoo_la_LIBADD = src.lo. It might be even be worthwhile adding to dependencies: libfoo_la_DEPENDENCIES = src.lo.

Though I don't see why just putting src.asm in libfoo_la_SOURCES wouldn't be sufficient.

Brett Hale
  • 21,653
  • 2
  • 61
  • 90
  • This is pretty much where I ended up too, and there are problems: first, the _.asm.lo_ command is only run once by libtool (I'm using a shell script as a front-end to yasm underneath, that shell script is only executed once in response to the command "make XXX.lo"); second, the _XXX.lo_ file is created in the top-level Makefile directory, not the source directory. I could change my shell script to create both _.libs/XXX.o_ and _XXX.o_ in a single execution, and I could move the _XXX.lo_ file explicitly, but doing that seems fragile (and wrong when not building a shared library). – Keith Bostic Sep 15 '16 at 14:56
  • Edit: I've figured out where I was going wrong on creating both static and shared objects, my script error. Is there a recipe for where libtool creates the _XXX.lo_ file? – Keith Bostic Sep 15 '16 at 15:32
0

This works (although I never did figure out how to get libtool to create the .lo file in the target directory, or to create the target directory's .libs directory).

The Makefile rule:

# Rule to build object files from asm files.
#
# XXX
# Libtool creates the .lo file in the directory where make is run. Move the file
# into place explicitly; I'm sure this is wrong, but have no idea how to fix it.
# Additionally, in a parallel make, the .libs file may not yet be created, check
# as necessary, but ignore errors.
.asm.lo:
        -d=`dirname $@`; test $d/.libs || mkdir $d/.libs
        $(LIBTOOL) --tag=CC --mode=compile sh $(srcdir)/dist/yasm.sh $< $@
        rm -f $@
        mv `basename $@` $@

A support shell script to do the yasm call:

#! /bin/sh

# Libtool support for yasm files, expect the first argument to be a path to
# the source file and the second argument to be a path to libtool's .lo file.
# Use the second argument plus libtool's -o argument to set the real target
# file name.
source=$1
target=`dirname $2`
while test $# -gt 0
do
        case $1 in
        -o)
                target="$target/$2"
                shift; shift;;
        *)
                shift;;
        esac
done

yasm -f x64 -f elf64 -X gnu -g dwarf2 -D LINUX -o $target $source
Keith Bostic
  • 21
  • 2