I'm having trouble getting the helloworld external to compile properly on Windows.

The main resource is apparently this: HOWTO write an External for puredata, and some previous posts on this topic are here: Compiling new external, Max/MSP microtuning externals to convert to pd

Bear with me, because working with the C compiler is still rather mysterious to me, so I may be making some obvious mistakes. I've installed the djgpp compiler, and followed all the instructions as best as I could. I'm working on XP. I put "m_pd.h" (from the pd/src/ folder) and "helloworld.c" in the same folder and from that directory on the command line (in a DOS "Command Prompt" window) typed:

gcc -c helloworld.c -o helloworld.o

As far as I can tell, this successfully produced the "helloworld.o" object file in the same directory as the "helloworld.c" file. Then I typed:

ld -export_dynamic -shared -o helloworld.dll helloworld.o -lc -lm

Which, as I understand, is the "linking" step, and the only difference between this command and the command for linux is that ".pd_linux" is replaced with ".dll". Anyway, the compiler responded with:

c:/progra~1/djgpp/bin/ld.exe: -shared not supported

So, not having any other ideas, I tried omitting the -shared flag:

ld -export_dynamic -o helloworld.dll helloworld.o -lc -lm

That produced this response:

c:/progra~1/djgpp/bin/ld.exe: warning: cannot find entry symbol xport_dynamic; defaulting to 000018d0
helloworld.o:helloworld.c:(.text+0x1e): undefined reference to `post'
helloworld.o:helloworld.c:(.text+0x37): undefined reference to `pd_new'
helloworld.o:helloworld.c:(.text+0x60): undefined reference to `gensym'
helloworld.o:helloworld.c:(.text+0x79): undefined reference to `class_new'
helloworld.o:helloworld.c:(.text+0x96): undefined reference to `class_addbang'

Why is -shared not supported and what can I do to fix that? I tried Microsoft Visual C++ Express Edition, but found the interface bewildering. I don't think I could even find the words "compile" and "link" in any menu...

Then I looked in the "0.README" file located in the pd/doc/6.externs/ directory, and found this line (in reference to the 3 example enternals in that folder):

To compile, type "make pd_linux", "nmake pd_nt", "make pd_irix5" or "make pd_irix6".

If I wanted to compile these, where would I even type this? Is "nmake" an actual command?

Then I tried poking around the GNU info files, and saw some vague information about "binutils" and "dlltool" but it is so beyond me right now that I'm turning here. Could someone please enumerate the steps required to take the C source file "helloworld.c" and make it into a usable object in pd without skipping any steps? I (and I'm sure many others) would greatly appreciate that.

Thanks in advance!

Alberto,

I figured it out. I made a few changes to your makefile, though:
1. added a path to m_pd.h
2. changed "rm -f $*.o ../$*.dll" to "rm -f $*.o $*.dll"
(the .dll file wasn't being removed from the working directory)
3. forced DEST to the pd/extra directory
4. removed CSYM since it's not being used
5. removed "current: pd_win"; changed "pd_win: $(NAME).dll" to "all: $(NAME).dll"
6. removed non-win stuff
7. removed the clean and install targets for right now
Hopefully these changes make it easier for the complete newbie. Anyway, with enormous thanks to AlbertoZ, here's a mini-tutorial for using my makefile.

1. if you're using pd-extended, save this as "m_pd.h" (into the same directory with
helloworld.c). If you're using pd-vanilla, you can skip this step.
2. save this code as "mk.mk" (into the same directory with helloworld.c):

# mk.mk -- invoke with "make -f mk.mk"

      NAME = helloworld
    PDPATH = "c:/Progra~1/pd"
   LDFLAGS = --export-dynamic -shared
WININCLUDE = -I $(PDPATH)/src
 WINCFLAGS = -DPD -DNT -W3 -WX -Werror -Wno-unused          \
             -mms-bitfields -Wno-parentheses -Wno-switch    \
             -O6 -funroll-loops -fomit-frame-pointer

all: $(NAME).dll
.SUFFIXES: .dll
.c.dll:
    gcc $(WINCFLAGS) $(WININCLUDE) -c -o $*.o $*.c
    gcc $(LDFLAGS) -o $*.dll $*.o $(PDPATH)/bin/pd.dll  
    strip --strip-unneeded $*.dll
    cp $*.dll $(PDPATH)/extra
    rm -f $*.o $*.dll

2. modify the PDPATH variable if needed to reflect the actual location of pd on your
system (MSYS will interpret c:/Program Files/pd as C:/Program, so use
c:/Progra~1/pd instead)
3. if you're using pd-extended, remove line 6 (WININCLUDE = -I $(PDPATH)/src) and
remove $(WININCLUDE) from line 14.
4. close all pd windows if any are open
5. in MSYS, navigate to the directory with helloworld.c and type: make -f mk.mk
(type make -s -f mk.mk if you want to hide the lengthy shell response)
6. the shell should respond with something like:
gcc -DPD -DNT -W3 -WX -Werror -Wno-unused -mms-bitfields -Wno-parentheses
-Wno-switch -O6 -funroll-loops -fomit-frame-pointer -I "c:/Progra~1/pd"/src -c -o
helloworld.o helloworld.c
gcc --export-dynamic -shared -o helloworld.dll helloworld.o
"c:/Progra~1/pd"/bin/pd.dll
strip --strip-unneeded helloworld.dll
cp helloworld.dll "c:/Progra~1/pd"/extra
rm -f helloworld.o helloworld.dll
7. a new helloworld.dll file should be saved into the pd/extra folder, and you should be
able to create the "helloworld" object in a new pd window.

Good luck!
middlepedal

Hi Middlepetal,

I also noticed that Mingw externals are "thin" instead of
the fat MSVC. Dunno why exactly. For sure the

strip --strip-unneeded $*.dll

strips everything unnecessary out from the .dll

Yes, you tailored the makefile perfectly for the
helloworld project. When you start mastering makefiles there is no
way back .

Regarding

>Also, I tried using your makefile as you said, but got the response:
>
> make: Nothing to be done for `current'.

be sure to first remove the .o and .dll from the current directory
that you probably had produced by compiling manually from
command line.

PS: how do you make colored, bold text in the forum?
I didn't realize it was possible :-0

cheers,

Alberto

AlbertoZ,

here's the info on formatting your forum posts:
http://puredata.hurleur.com/help.php.

Have fun!
middlepedal

Thanks for the detailed tutorial

>7. Access the pd library file:
> a. Open Windows Explorer or My Computer.
> b. Navigate to the pd/bin/ directory on your system.
> c. Right-click on pd.lib (file type is: Object File Library) and select Copy.
> d. Navigate to the C://TEMP/ directory on your system.
> e. Paste the copy of pd.lib in the C://TEMP/ directory (right-click or Ctrl-V).

Where can I find the pd.lib file? I'm using pd-extended, and there is not a single .lib file in my pd/bin directory.

-JoGi

@jogistar said:

Where can I find the pd.lib file? I'm using pd-extended, and there is not a single .lib file in my pd/bin directory.

Mmmh, I was not able to find it too in my pletora of win PD distributions.
I suspect pd.lib is:

a) pd.dll, which is a "dynamically linked library" in windows (and by chance
it is referred as pd.lib), which is located in pd/bin
pd.dll as seen by MSVC integrated environment (???).

Boh... let us know... otherwise try the dark side of the force (MinGW way)

All the best,

Alberto

@AlbertoZ said:

@jogistar said:

Where can I find the pd.lib file? I'm using pd-extended, and there is not a single .lib file in my pd/bin directory.

Mmmh, I was not able to find it too in my pletora of win PD distributions.
I suspect pd.lib is:

a) pd.dll, which is a "dynamically linked library" in windows (and by chance
it is referred as pd.lib), which is located in pd/bin
pd.dll as seen by MSVC integrated environment (???).

Hi all,

I don't think pd.lib is the same as pd.dll. pd.lib, as appears in pd-vanilla, also does not appear to be in the CVS repository. I've included pd.lib as an attachment with this post, but you must be a member to download the attachment (membership is free).

Hope it helps,
middlepedal

http://www.pdpatchrepo.info/hurleur/pd.lib

Thanks AlbertoZ!

It took me some courage to try the old-man unix style compilation, but it did work and I got my "Hello World!" printed out. All in all it took me maybe in 15 minutes.

You really should make a wiki-page out of this to puredata.org!

It's just a fact that people are scared of unknown... if one is not used to use Unix, then the cryptic lines like the following are very scary:

>f. type:
>ld -export_dynamic -shared -o helloworld.dll helloworld.o c:/Programmi/pd039e
>xt4/bin/pd.dll

It would make it easier if you could even very shortly explain what's going to happen in each step. For example this was useful small note:
"Then we need MSYS which is a shell (an interpreter of the commands, like a colorful dos prompt "

In the original wiki (http://puredata.org/docs/developer/mingw) it was only:
"Install this with all of the defaults: MSYS-1.0.10.exe"

For a scary windows-person like me it's nice to know why I should install that.

In your wiki page you could link also the followink make-file tutorial:
http://www.eng.hawaii.edu/Tutor/Make/index.html

Thanks a lot,

-JoGi

I found also a nice tutorial on how to compile the "Hello world" example with DevC++ free integrated development environment.

http://www.youngmusic.org/wiki/index.php/PD-linking-tutorial

Hi, sorry to pull up this old topic.

This somewhat overlaps with my recent post to [pd-dev] list.
After the posting, I had made some progress and came up with a new question while discovering this thread which seemed very relevant.

Struggling to get my externs built on Windows, I've been working both in VC++ Express 2008 and MSYS.

Under both environments, the "hello world" code on the "EXTERNALS HOWTO" page build fine. Well, with minimal knowledge of C and zero experience in mangling with existing OSS, I did spend a good amount of time with VC++ before reaching configurations identical to ones mentioned earlier in this thread.

However, with the next "counter" example, I would face problems related to the fact that "s_float" cannot resolved.

Under VC++, the link would simply fail due to the unresolved _s_float symbol... until this morning.. I've tried linking to the pd.lib file contained in a version of Pd later than I tried earlier in order to gather error messages for this post. For some reason it seems to work now.

The situation remains the same with MSYS.
I get the following message during linking. Although the .dll file is created, Pd does not load the external properly.

$ ld -E -shared -o gcounter.dll gcounter.o pd.dll
Info: resolving _s_float by linking to __imp__s_float (auto-import)

(gcounter is just a name a gave to the simple counter example to avoid conflict with existing objects in pd-extended)

After working on this for a few nights, I've finally got files built in VC++ working so I am somewhat relaxed now.
I would, however, appreciate advise on what may be going on with the MSYS builds. Again, "helloworld" builds and runs great. Only after s_float symbols are introduced do I see behaviors I cannot understand.

Thanks.

--
David Shimamoto

Hi David,

Did you resolve the problems with the $s_float in the counter example? I am getting the same problem using Dev-C++.

Thanks,
Joe

Hello everybody,

I'm working with files that was written several years ago on other Windows versions. I have to compile an external in order to start my real work, but I'm not an expert in C programming.

I've tried to compile the DLL with both Visual C++ 2008 and MinGW. I'm not Trying to compile helloworld.c but another file (M2M~.c) that I have to work with. I have many header files (.h) associated with M2M~.c.

With Visual C++ 2008, I have done exactly the same thing than middlepedal but I cannot compile, I have an error message such as (this is in french) :

Édition des liens en cours...
LINK : error LNK2001: symbole externe non résolu M2M~_setup
C:\Users\Teaiki\Documents\Visual Studio 2008\Projects\M2M~\Debug\M2M~.lib : fatal error LNK1120: 1 externes non résolus

Is there a great différence between Visual C++ 2008 and Visual C++ 2005?

With MinGW, I have done exactly the same thing than AlbertoZ, and I have a lot of error message such as : "undefined reference to ..."

What should I do?

Can someone help me please?

Thank you in advance

Teaiki

Dunno if this thread is completely dead, but:

I followed instructions int his thread and got the helloworld to build in VS2005. I compiled in debug mode. The helloworld.dll loads and works in PD. BUT, if I switch to relese mode, pd crashes every time. I have been fiddling aournd with some of the settings and it seems that the "Generate Debug info" is the culprit.

Any help appreciated, I'm going nuts here.

I also ended up compiling in MinGW, with eventual success and not too much trouble. I had to figure out how to do a build file (most of my limited experience is in VS), but not too hard.

You mean like this one?
Yes, I have been all over the internet. Like I said, I eventually solved my problem using MinGW. I don't know why it worked and VS had a problem. Probably my own lack of experience had something to do with it.

@joelakes said:

Hi David,

Did you resolve the problems with the $s_float in the counter example? I am getting the same problem using Dev-C++.

Thanks,
Joe

I was having the same problem. Also in the [pan~] signal class example with &s_signal.

But I finally solved it, or at least found a way around it that seems to work.
In How to Write PD Externals there's a line explaining that s_signal refers to the
string "signal" in a lookup table somewhere, so I tried to just replace &s_signal with "signal" each place it was used. Of course, this didn't work.

Later I noticed that anywhere else a string appeared, it was added with gensym("string"). So this time I replaced &s_signal with gensym("signal") and it actually worked.

My ideas on what's going on are either:
A. The external is compiled before "signal" is added to the table.
B. "signal" is never added to the table, unless you do it
C. The external can't see the table, for what ever reason.

These are just guesses. I'm learning as I go, and not very familiar with C yet.

I would like to know however if this is a good practice or a hack.
Also, should I use gensym() every time s_signal appears, or does it just need to be called once? ie Will it cause any problems to call gensym() multiple times with the same argument?

Hopefully this will help someone else out there having the same problem.

I got as far as {external}.o

It seems that I need to include a flag -std=c99 for some trig definitions. Any ideas on how to do this using MinGW32?

@middlepedal @AlbertoZ