On Jul 11, 2011, at 1:29 PM, Hans-Christoph Steiner wrote:
On Jul 11, 2011, at 1:06 PM, Patrice Colet wrote:
----- "Patrice Colet" colet.patrice@free.fr a écrit :
The problem I'm encountering on win32 with makefile.am is that pd.dll is not built
following this doc page:
http://serghei.net/docs/programming/autobook-1.1/dlls20with20libtool.html
I've added those lines in makefile.am:
if WINDOWS LIBS += -lwsock32 -lwinmm -lole32 pd_CFLAGS += -DUSEAPI_MMIO -DPD_INTERNAL pd_SOURCES += s_audio_mmio.c s_midi_mmio.c lib_LTLIBRARIES = libpd.la libpd_la_SOURCES = $(pd_sources) libpd_la_LDFLAGS = -no-undefined pd_LDADD = libpd.la bin_SCRIPTS = endif
it's getting closer because dll building is initiated:
Creating library file: .libs/libpd.dll.a
pd.dll isn't a libtool standard file
but the linker complains:
pd-m_sched.o:m_sched.c:(.text+0x1514): undefined reference to `_imp__pthread_mutex_lock' pd-m_sched.o:m_sched.c:(.text+0x1528): undefined reference to `_imp__pthread_mutex_unlock' pd-m_sched.o:m_sched.c:(.text+0x1920): undefined reference to `_imp__pthread_mutex_trylock'
pd-s_loader.o:s_loader.c:(.text+0x233): undefined reference to `dlopen' pd-s_loader.o:s_loader.c:(.text+0x247): undefined reference to `dlsym' pd-s_loader.o:s_loader.c:(.text+0x4a7): undefined reference to `dlerror' pd-d_soundfile.o:d_soundfile.c:(.text+0x27f): undefined reference to `_imp__pthread_mutex_lock'
try changing:
LIBS += -lwsock32 -lwinmm -lole32
to:
LIBS += -lwsock32 -lwinmm -lole32 -lpthreadGC2 -ldl
.hc
That makes me think.... so ./configure is finding libdl find, and then setting HAVE_LIBDL, and then the code in s_loader.c is going to do both HAVE_LIBDL and the MSW section below it. So I guess we should force this build system to not use HAVE_LIBDL on Windows, or fix the define to be something like:
#ifdef HAVE_LIBDL dlobj = dlopen(filename, RTLD_NOW | RTLD_GLOBAL); if (!dlobj) { post("%s: %s", filename, dlerror()); class_set_extern_dir(&s_); return (0); } makeout = (t_xxx)dlsym(dlobj, symname); /* fprintf(stderr, "symbol %s\n", symname); */ -#endif -#ifdef MSW +#elif defined(_WIN32) sys_bashfilename(filename, filename); ntdll = LoadLibrary(filename); if (!ntdll) { post("%s: couldn't load", filename); class_set_extern_dir(&s_); return (0); } makeout = (t_xxx)GetProcAddress(ntdll, symname); +#else +#error "No dynamic loading mechanism found!" #endif
.hc
<snip>
it's seems closer
----- "IOhannes m zmoelnig" zmoelnig@iem.at a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-11 17:59, Hans-Christoph Steiner wrote:
We have the opposite problem than that automake hack is trying to solve. When ASIO is including, then everything including
portaudio
is
built and linked using g++. Portaudio fails to build with g++, so
we
need to find a way to make only ASIO build with g++, while the
rest
build with gcc. I think automake will still choose g++ for
linking
since its choosing g++ for ASIO.
ah thanks for clarifying the problem.
however: automake will chose the _compiler_ on a file-per-file
basis;
so forcing the _linker_ to be CXX for pd, should have no effect on the compilining portaudio (and creating the portaudio library)
fgamdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4bIPIACgkQkX2Xpv6ydvTdYwCfUlNGwDybirLriNT1O6UwV8v1 j68AnjgGtdThIklLxRGBSN9vK4anSbjx =HAmS -----END PGP SIGNATURE-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- Patrice Colet
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- Patrice Colet
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
----------------------------------------------------------------------------
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore