PD Compiler doesn't seem to work

Home Forums OWL Patches PD Compiler doesn't seem to work

This topic contains 9 replies, has 4 voices, and was last updated by  canyin 1 year, 1 month ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #2141

    JoseFuzzNo
    Participant

    Hi,

    I think there’s still an issue with the PD compiler. Whatever I try to compile, the linker gives me the following error:

    /tmp/ccWHC19B.ltrans1.ltrans.o: In function'cBinop_k_onMessage.constprop.13':
    <artificial>:(.text+0x40): undefined reference to 'alloca'
    /tmp/ccWHC19B.ltrans1.ltrans.o: In function 'hv_vscheduleMessageForReceiver.constprop.11':
    <artificial>:(.text+0xb4): undefined reference to 'alloca'
    collect2: error: ld returned 1 exit status
    make: *** [/tmp/owl-build-WAxB2n/patch.elf] Error 1
    ERROR: Patch build failed.

    I downloaded the OwlProgram and it gives me the same error. I can compile and run C++ code but not PD.
    I tried some patches in the gallery, the template, even an [adc~] and [dac~] with nothing else in the patch.

    The arm-none-eabi-gcc -v command gives me:
    gcc version 4.9.3 20150529 (prerelease) (15:4.9.3+svn227297-1)
    I also tried the 5.2.1 gcc but the error output was so big that I didn’t bother to search for the errors. 🙂

    It seems like a Makefile problem but I can’t figure it out. Tomorrow is another day.

    • This topic was modified 1 year, 10 months ago by  JoseFuzzNo.
    #2143

    Martin Klang
    Keymaster

    I can confirm I’m getting the same error. They’ve recently updated the Heavy compiler, I think I need to bring the Makefile into line.

    #2144

    Martin Klang
    Keymaster

    I’ve pushed some changes to the master branch which fixes this problem and brings us up to date with the latest Heavy utilities.

    It turns out alloca must be defined as this for gcc arm to be happy (I’ve no idea why):
    #define hv_alloca(_n) __builtin_alloca(_n)

    I’ve also deployed the changes to the server and have tested that the PD template patch builds ok, so it should all be good to go.

    Note that at the moment, building a PD patch locally first time usually requires calling the make command twice. If you see lots of errors like undefined reference to hv_owl_new it is because the files generated by Heavy have not been pulled into the dependencies yet, and so have not been compiled. I’d like to fix this in a future re-haul of the Makefile, but I think it will require a recursive make.

    #2146

    JoseFuzzNo
    Participant

    It works! Thanks a lot.

    Yes, I noticed those errors. Duplicating the last line on the Makefile (@make $(PATCH_OBJS)) doesn’t complain any more 😀 Not pretty but it works.

    #2147

    JoseFuzzNo
    Participant

    No, it doesn’t. Once the object files are compiled the make command works without errors. That confused me.

    #2180

    jayrope
    Participant

    Is this issue resolved in the meantime, e.g. the compiler is working now?

    #2218

    JoseFuzzNo
    Participant

    Yes, it does! 😉

    #2222

    Martin Klang
    Keymaster

    The master branch of OwlProgram now has a much improved build. No need to run heavy compilations twice. And you no longer have to specify the extra ‘heavy’ target – just make HEAVY=patchname.pd patch|web|run|store will do.

    It’s a fairly big change, if you encounter any issues let me know.

    #2549

    canyin
    Participant

    Just got the next error while trying to compile my pd patch (https://hoxtonowl.com/patch-library/patch/Granular_delay) for owl in the online compiler.

    Traceback (most recent call last): File "./Tools/Heavy/uploader.py", line 464, in <module> main() File "./Tools/Heavy/uploader.py", line 456, in main token=args.token) File "./Tools/Heavy/uploader.py", line 365, in upload except requests.ConnectTimeout as e: AttributeError: 'module' object has no attribute 'ConnectTimeout' make[1]: *** [/tmp/owl-build-MAIXN9/Source/Heavy_owl.h] Error 1 make: *** [heavy] Error 2 ERROR: Patch build failed.

    At first I thought it’s a fully complier related error but then I tried with another patch and it worked just fine. Is the patch too heavy or something?

    • This reply was modified 1 year, 1 month ago by  canyin.
    #2551

    canyin
    Participant

    Solved.

    The compiler didn’t like it when I connected multiple sources in the same delay line.

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.


Latest News

Links

Follow us on Twitter