#1087 template.pd_linux not created

pd-devel (18)
Funs Seelen

Using the MakefileTemplate (version 1.0.14) by H.C. Steiner on debian/ubuntu no .pd_linux file is created when typing `make' or `make install'. Now every single class has to be loaded separately. `make clean' actually does remove any mylibrary.pd_linux although it has never existed.


  • IOhannes m zmölnig

    this is most likely by intention: since you cannot use an objectlcass "foo" without creating [foo] and the latter will automatically load foo.pd_linux if needed, there is not much drawback to this method.

    the template-Makefile will build a pd_linux file for each C-file listed in "SOURCES" (so if you have "SOURCES=foo.c" then you should end up with a "foo.pd_linux"

    however, you can also create a single-binary-multi-object library by running `make mylibrary` (it's all there, but not the default)...that's also the reason why it is removed in the "clean" target.

    Last edit: IOhannes m zmölnig 2013-06-04
  • IOhannes m zmölnig

    • status: open --> pending-works-for-me
  • Funs Seelen

    Funs Seelen - 2013-06-02
    • status: pending-works-for-me --> open-works-for-me
  • Funs Seelen

    Funs Seelen - 2013-06-02

    Thanks for your comment IOhannes.

    I considered this a bug because I had the idea that loading a library by loading all classes separately was not the standard way of doing, at least it is not a very easy way if your library contains more than one class. This LibraryTemplate or MakefileTemplate (which is great, thanks for that, hc!) however is created to standardize the format of external libraries.

    Anyway, If I create a $(LIBRARY_NAME).c and add it to SOURCES and put setup() functions in it, like the example found at http://puredata.info/docs/developer/LibraryTemplate ...

    void mycobject_setup(void);

    void template_setup(void) {

    ... Pd complains:
    ./$(LIBRARY_NAME).pd_linux: ./$(LIBRARY_NAME).pd_linux: undefined symbol: mycobject_setup
    $(LIBRARY_NAME): can't load library

    Extending $(LIBRARY_NAME).c with a struct, t_class* et cetera (like I saw in other `libraries that use this template'), including in EXTRA DIST and running `make $(LIBRARY_NAME)' results in the following error

    make: *** No rule to make target `lib$(LIBRARY_NAME).o', needed by `$(LIBRARY_NAME)'. Stop.

    which is made clear in the Makefile:

    # this links everything into a single binary file
    chmod a-x $(LIBRARY_NAME).$(EXTENSION)

    But I don't have any libmylibrary.o and don't know where to get it.

    Probably I'm doing something very wrong somewhere or just don't understand some essential part. Now I tend to just leave it the way it was and load classes separately, but I'd prefer to prevent people from complaining that my library doesn't load unless they load all classes individually, like ...

    Pd libraries to load on startup:


    I hope this makes sense in some way :)

  • IOhannes m zmölnig

    • status: open-works-for-me --> pending-works-for-me
  • IOhannes m zmölnig

    obviously there are many different "standard" ways to create libraries.
    one of those standards is proposed by hc, who is also the main author of the template/Makefile and the wiki-page you linked to, in order to support this standard.

    the main point of this standard is that each objectclass (such as [foo]) has a separate binary on the filesystem ("foo.pd_linux"), created from a single source-file "foo.c".
    the main advantage of this setup is that it is very simple and easy to use and understand: for each C-file you have, you get a single binary; and for each binary you have you get a single objectclass.
    (the main drawback is obviously, that it is very simple and cannot fit the bill for complicated libraries (nor should it), where you have loads of inter-object dependencies (on the source-code level).

    in most cases, this simple setup is enough. but it means that your sentence " I had the idea that loading a library by loading all classes separately was not the standard way of doing" is simply wrong: the very idea of the the template library format is that you have to load all classes separately.
    since loading is as easy as creating an object (which you have to do in any case), there is (theoretically) no penalty for the user.

    as for your final problem:
    if you do want an old-school multi-object-binary, the template/Makefile allows this, but it's probably not well documented.
    esp. the Makefile will use a file named $(LIBRARY_NAME).c (e.g. "template.c", for the "template" library) as the glue.
    the thing that is undocumented is, that $(LIBRARY_NAME).c **must not** be part of SOURCES.
    SOURCES is really only for the standalone files that are to be built into objectclasses.

    a makefile that has been adjusted like following (and otherwise has been left intact)
    SOURCES=foo.c bar.c

    will by default create "foo.pd_linux" and "bar.pd_linux".
    but you can also do "make pizza" and it will create a "pizza.pd_linux" - but for this you will need a file pizza.c which is not in SOURCES and which contains something like:

    void pizza_setup(void) {

  • IOhannes m zmölnig

    so just to make sure that my main message did not get concealed by the long reply:

    do not add $(LIBRARY_NAME).c to your SOURCES!

  • Funs Seelen

    Funs Seelen - 2013-06-03

    Thanks for your indeed long reply and especially for the explanation of the "standard".
    The problem was the lib$(LIBRARY_NAME).o the makefile asked for, for I did not make use of any shared code. Adding two empty dummy files lib$(LIBRARY_NAME).c and $(LIBRARY_NAME).h fixed it. Now it works and I'm happy :).

  • Funs Seelen

    Funs Seelen - 2013-06-03
    • status: pending-works-for-me --> closed-fixed
  • IOhannes m zmölnig

    it would be great if you added the missing information to the wiki, to help future coders

  • Funs Seelen

    Funs Seelen - 2013-06-03

    Done. I didn't know I had write access to this wiki actually ...

  • Funs Seelen

    Funs Seelen - 2013-06-03
    • status: closed-fixed --> open-fixed
  • IOhannes m zmölnig

    • status: open-fixed --> closed-works-for-me
    Last edit: IOhannes m zmölnig 2013-06-05


Cancel  Add attachments

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks