[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: First package: A library



On Tue, May 19, 1998 at 10:53:47PM +0100, James Troup wrote:
> Fabrizio Polacco <fpolacco@icenet.fi> writes:
> 
> > -shared -Wl,-soname,libgc4.so.4 -o libgc4.so.4.13alpha1 
> 
> add "-lc", and run dpkg-shlibdeps on the library with
> ${shlibs:Depends} in the Depends: line in debian/control.

Absolutely correct.
I use in the Makefile:

=======================
VER     = $(shell expr `pwd` : '.*-\([0-9.]*\)')
MVER    = ${shell expr `pwd` : '.*-\([0-9]*\).[0-9]*'}

static  = ${libname}.a
shared  = ${libname}.so.${VER}
soname  = ${libname}.so.${MVER}

static ${static}:       ${objs}
	$(AR) $(ARFLAGS) ${static} $^

shared ${shared}:       ${objs}
	${CC} ${CFLAGS} -shared -Wl,-soname,${soname} $^ -lc ${LIBS} -o ${shared}

install_run:    ${shared}
	install -m755 -d        ${libdir}
	install -m644 ${shared} ${libdir}

install_debug:  ${shared} ${static}
	install -m755 -d        ${libdir}/debug
	install -m644 ${static} ${libdir}/debug
	install -m644 ${shared} ${libdir}/debug/${soname}

=======================

As you can notice, this fragment is quite indipendent from the package, once
you have defined  libname=lib??  and put in   obj   the list of the object
files even including the subdir path relative to pwd.
Then you can call the makefile from the rules file passing different options
for the different libs:

# ======== build and install 'C' shared lib ========
	${MAKE} -f debian/Makefile  install_run \
		libname=libmine CFLAGS="-g -O2"
# ======== build and install 'C' debug shared lib ========
	${MAKE} -f debian/Makefile  install_debug \
		libname=libmine CFLAGS="-g3 -DDEBUG" create_debug_lib=1 

With a few added vars I use the same makefile to build also the c++ libs of
the same package.

This is possible because I use new makefiles instead of the original one
(which I use only to get lists of objects and programs to build).
In fact several upstream autors have strange ideas on how you should build the
"work"; for example GNU forces the use of rpath, as well as those using
libtool; in my case, the makefile built only a static lib and was projected
around the idea that will build only one of the several type of lib at once,
not _all_ of them in sequence, as we do building packages.

Also, upstream makefiles usually try to avoid problems with weak make
utilities in other unices, resulting in complicated and unreadable makefiles.
As you can notice, in the makefile above there are no rules to compile etc.
All what is done in the default way should be done using embedded rules. this
permits to do "differently" simply using make's overriding capability, which
can be enabled passing a variable:

ifdef change_cpp_to_cc
%.cc:%.cpp
	ln -fs $(^F) $@ && echo -e " $@\c" >>debian/cc_links

linkclean:
	-test -f debian/cc_links && for link in `cat debian/cc_links`; \
		do      test -L $${link} && rm -f $${link}; done    
	-test -f debian/cc_links && rm -f debian/cc_links

endif

This makefile fragment trasform all c++ sources ending in .cpp into .cc so 
you can use the implicit rules in make.
To activate it simply call it from the rules file:
        ${MAKE} -f debian/Makefile  install_run change_cpp_to_cc=1

In the clean target of the rules file, add:
        ${MAKE} -f debian/Makefile  linkclean change_cpp_to_cc=1

(This is an example, as you don't strictly need the ifdef for this, but it's
good practice not to leave overrides enabled as default)
(And it's not an override strictly speaking; the argument "create_debug_lib=1"
that I use when building a debug shared lib activates a real override to split
the compile stage into cc+asm and editing the .s in the middle.)


> > Install in debian/tmp/DEBIAN a postinst with the instruction
> > 	ldconfig
> 
> *Iff* "$1" = "configure"; try something like:
> 

Oh, yes!.
I remember the discussion, but on my machine all the ldconfig are alone :-(
Anyway, I'm in fault, as I have not yet made this way :-(

> > The -dev package must depend on the main package
> 
> And almost certainly on libc6-dev.

or generally speaking on the the -dev lib of the language for which the lib
has been built
(e.g: a C lib to be linked to C++ progs will depend on libstdc++-dev )

Depends: libc6-dev, <main-lib> (=${Source-Version}), ${shlibs:Depends}

or

Depends: libstdc++-dev, <main-lib>++ (=${Source-Version}), ${shlibs:Depends}

where the last should be only if you have some executables and you call 
dpkg-shlibdeps on them (utility progs go generally in the -dev package or in a
separate package -util ).
This was for -dev package, as the main package have only 
Depends: ${shlibs:Depends}
and call dpkg-shlibdeps on the shared lib.

The -dbg package instead has
Depends: libc6-dev, ${shlibs:Depends}
and call dpkg-shlibdeps on the shared lib.



fab - who isn't a lib expert, but experiments hard.
-- 
| fpolacco@icenet.fi    fpolacco@debian.org    fpolacco@pluto.linux.it
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E
> support the open-source initiative! http://www.opensource.org/


--
To UNSUBSCRIBE, email to debian-mentors-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: