----- "Hans-Christoph Steiner" hans@at.or.at a écrit :
Ah, right, supporting LTLIBRARIES would be a bigger reorg. Any luck
with the LD=$(CXX) option?
Still same error, this is exactly like this one:
http://lists.puredata.info/pipermail/pd-cvs/2010-08/020963.html
the only solution that is working so far is about using CC to compile portaudio, I don't know if I could get time to reorg the build system for libtool conveniences.
.hc
On Jul 2, 2011, at 7:01 AM, Patrice Colet wrote:
I've found the odd part of that page is that they use LTLIBRARIES variable while pd/src/Makefile.am doesn't.
On Fri, 01 Jul 2011 19:36 +0200, "IOhannes m zmölnig"
On 07/01/2011 06:24 PM, Hans-Christoph Steiner wrote:
the trick to use g++ for linking, is to use a dummy .cpp file,
so
autotools will automatically choose g++.
something like:
<snip> nodist_EXTRA_pd_SOURCES= if PORTAUDIO nodist_EXTRA_pd_SOURCES += dummy.cpp endif </snip>
It would be worth trying:
LD=$CXX
http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Li...
That solution at the bottom of that page looks easy but a bit odd.
I
suppose its the 'official' way. Patco, do you think you can try
to
get that working?
.hc
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- Patrice Colet
Mistrust authority - promote decentralization. - the hacker ethic
On Jul 3, 2011, at 3:31 AM, Patrice Colet wrote:
----- "Hans-Christoph Steiner" hans@at.or.at a écrit :
Ah, right, supporting LTLIBRARIES would be a bigger reorg. Any luck
with the LD=$(CXX) option?
Still same error, this is exactly like this one:
http://lists.puredata.info/pipermail/pd-cvs/2010-08/020963.html
the only solution that is working so far is about using CC to compile portaudio, I don't know if I could get time to reorg the build system for libtool conveniences.
I tried changing the "if ASIO" section in pd/Makefile.am to this:
if ASIO EXTRA_SUBDIRS += asio # automake hack to force linking with g++ lib_LTLIBRARIES = libdummy.la libdummy_la_SOURCES = # Dummy C++ source to cause C++ linking. nodist_EXTRA_libdummy_la_SOURCES = dummy.cxx endif
And it did indeed switch to using g++, but for compiling too, and that triggers the same issue. It seems that you can't compile portaudio WMME with g++, and the current build system is using g++ by default. So I think we actually need the opposite than that solution. If we include the ASIO files, automake switches to g++. So we need to force portaudio to always be built using gcc. Anyone have any ideas there?
.hc
.hc
On Jul 2, 2011, at 7:01 AM, Patrice Colet wrote:
I've found the odd part of that page is that they use LTLIBRARIES variable while pd/src/Makefile.am doesn't.
On Fri, 01 Jul 2011 19:36 +0200, "IOhannes m zmölnig"
On 07/01/2011 06:24 PM, Hans-Christoph Steiner wrote:
> the trick to use g++ for linking, is to use a dummy .cpp file,
so
> autotools will automatically choose g++. > > something like: > <snip> > nodist_EXTRA_pd_SOURCES= > if PORTAUDIO > nodist_EXTRA_pd_SOURCES += dummy.cpp > endif > </snip>
It would be worth trying:
LD=$CXX
http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Li...
That solution at the bottom of that page looks easy but a bit odd.
I
suppose its the 'official' way. Patco, do you think you can try
to
get that working?
.hc
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- Patrice Colet
Mistrust authority - promote decentralization. - the hacker ethic
-- Patrice Colet
----------------------------------------------------------------------------
Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs
I've removed this in configure.ac:
# ASIO is a C++ library, so if its included, then use g++ to build CC=g++
compiles fine, only pd.exe is not working but pd.dll is fine, everything is built.
from all I've read in gnu manuals, automake automatically set g++ for cpp files so there is no need to set CC.
----- "Hans-Christoph Steiner" hans@at.or.at a écrit :
On Jul 3, 2011, at 3:31 AM, Patrice Colet wrote:
----- "Hans-Christoph Steiner" hans@at.or.at a écrit :
Ah, right, supporting LTLIBRARIES would be a bigger reorg. Any
luck
with the LD=$(CXX) option?
Still same error, this is exactly like this one:
http://lists.puredata.info/pipermail/pd-cvs/2010-08/020963.html
the only solution that is working so far is about using CC to compile portaudio, I don't know if I could get time to reorg the build system for libtool conveniences.
I tried changing the "if ASIO" section in pd/Makefile.am to this:
if ASIO EXTRA_SUBDIRS += asio # automake hack to force linking with g++ lib_LTLIBRARIES = libdummy.la libdummy_la_SOURCES = # Dummy C++ source to cause C++ linking. nodist_EXTRA_libdummy_la_SOURCES = dummy.cxx endif
And it did indeed switch to using g++, but for compiling too, and that
triggers the same issue. It seems that you can't compile portaudio WMME with g++, and the current build system is using g++ by default.
So I think we actually need the opposite than that solution. If we include the ASIO files, automake switches to g++. So we need to force
portaudio to always be built using gcc. Anyone have any ideas there?
.hc
.hc
On Jul 2, 2011, at 7:01 AM, Patrice Colet wrote:
I've found the odd part of that page is that they use LTLIBRARIES variable while pd/src/Makefile.am doesn't.
On Fri, 01 Jul 2011 19:36 +0200, "IOhannes m zmölnig"
On 07/01/2011 06:24 PM, Hans-Christoph Steiner wrote: > >> the trick to use g++ for linking, is to use a dummy .cpp
file,
so
>> autotools will automatically choose g++. >> >> something like: >> <snip> >> nodist_EXTRA_pd_SOURCES= >> if PORTAUDIO >> nodist_EXTRA_pd_SOURCES += dummy.cpp >> endif >> </snip> > > It would be worth trying: > > LD=$CXX >
http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Li...
That solution at the bottom of that page looks easy but a bit
odd.
I
suppose its the 'official' way. Patco, do you think you can try
to
get that working?
.hc
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- Patrice Colet
Mistrust authority - promote decentralization. - the hacker ethic
-- Patrice Colet
Programs should be written for people to read, and only incidentally
for machines to execute.
- from Structure and Interpretation of Computer Programs
Hmm, that sounds like progress. Perhaps removing CC=g++ and then adding something like this would work:
if ASIO EXTRA_SUBDIRS += asio # automake hack to force linking with g++ lib_LTLIBRARIES = libdummy.la libdummy_la_SOURCES = # Dummy C++ source to cause C++ linking. nodist_EXTRA_libdummy_la_SOURCES = dummy.cxx endif
.hc
On Jul 5, 2011, at 7:04 AM, Patrice Colet wrote:
I've removed this in configure.ac:
# ASIO is a C++ library, so if its included, then use g++ to build CC=g++
compiles fine, only pd.exe is not working but pd.dll is fine, everything is built.
from all I've read in gnu manuals, automake automatically set g++ for cpp files so there is no need to set CC.
----- "Hans-Christoph Steiner" hans@at.or.at a écrit :
On Jul 3, 2011, at 3:31 AM, Patrice Colet wrote:
----- "Hans-Christoph Steiner" hans@at.or.at a écrit :
Ah, right, supporting LTLIBRARIES would be a bigger reorg. Any
luck
with the LD=$(CXX) option?
Still same error, this is exactly like this one:
http://lists.puredata.info/pipermail/pd-cvs/2010-08/020963.html
the only solution that is working so far is about using CC to compile portaudio, I don't know if I could get time to reorg the build system for libtool conveniences.
I tried changing the "if ASIO" section in pd/Makefile.am to this:
if ASIO EXTRA_SUBDIRS += asio # automake hack to force linking with g++ lib_LTLIBRARIES = libdummy.la libdummy_la_SOURCES = # Dummy C++ source to cause C++ linking. nodist_EXTRA_libdummy_la_SOURCES = dummy.cxx endif
And it did indeed switch to using g++, but for compiling too, and that
triggers the same issue. It seems that you can't compile portaudio WMME with g++, and the current build system is using g++ by default.
So I think we actually need the opposite than that solution. If we include the ASIO files, automake switches to g++. So we need to force
portaudio to always be built using gcc. Anyone have any ideas there?
.hc
.hc
On Jul 2, 2011, at 7:01 AM, Patrice Colet wrote:
I've found the odd part of that page is that they use LTLIBRARIES variable while pd/src/Makefile.am doesn't.
On Fri, 01 Jul 2011 19:36 +0200, "IOhannes m zmölnig" > On 07/01/2011 06:24 PM, Hans-Christoph Steiner wrote: >> >>> the trick to use g++ for linking, is to use a dummy .cpp
file,
so >>> autotools will automatically choose g++. >>> >>> something like: >>> <snip> >>> nodist_EXTRA_pd_SOURCES= >>> if PORTAUDIO >>> nodist_EXTRA_pd_SOURCES += dummy.cpp >>> endif >>> </snip> >> >> It would be worth trying: >> >> LD=$CXX >> > >
http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Li...
That solution at the bottom of that page looks easy but a bit
odd.
I
suppose its the 'official' way. Patco, do you think you can try
to
get that working?
.hc
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- Patrice Colet
Mistrust authority - promote decentralization. - the hacker ethic
-- Patrice Colet
Programs should be written for people to read, and only incidentally
for machines to execute.
- from Structure and Interpretation of Computer Programs
-- Patrice Colet
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
oopse I didn't see that pd.dll isn't deleted by make clean, if fact it isn't even built, sorry I'll try something else tomorrow.
----- "Hans-Christoph Steiner" hans@at.or.at a écrit :
Hmm, that sounds like progress. Perhaps removing CC=g++ and then adding something like this would work:
if ASIO EXTRA_SUBDIRS += asio # automake hack to force linking with g++ lib_LTLIBRARIES = libdummy.la libdummy_la_SOURCES = # Dummy C++ source to cause C++ linking. nodist_EXTRA_libdummy_la_SOURCES = dummy.cxx endif
.hc
On Jul 5, 2011, at 7:04 AM, Patrice Colet wrote:
I've removed this in configure.ac:
# ASIO is a C++ library, so if its included, then use g++ to build CC=g++
compiles fine, only pd.exe is not working but pd.dll is fine, everything is built.
from all I've read in gnu manuals, automake automatically set g++ for cpp files so there is no need to set CC.
----- "Hans-Christoph Steiner" hans@at.or.at a écrit :
On Jul 3, 2011, at 3:31 AM, Patrice Colet wrote:
----- "Hans-Christoph Steiner" hans@at.or.at a écrit :
Ah, right, supporting LTLIBRARIES would be a bigger reorg. Any
luck
with the LD=$(CXX) option?
Still same error, this is exactly like this one:
http://lists.puredata.info/pipermail/pd-cvs/2010-08/020963.html
the only solution that is working so far is about using CC to compile portaudio, I don't know if I could get time to reorg the build system for libtool conveniences.
I tried changing the "if ASIO" section in pd/Makefile.am to this:
if ASIO EXTRA_SUBDIRS += asio # automake hack to force linking with g++ lib_LTLIBRARIES = libdummy.la libdummy_la_SOURCES = # Dummy C++ source to cause C++ linking. nodist_EXTRA_libdummy_la_SOURCES = dummy.cxx endif
And it did indeed switch to using g++, but for compiling too, and
that
triggers the same issue. It seems that you can't compile
portaudio
WMME with g++, and the current build system is using g++ by
default.
So I think we actually need the opposite than that solution. If we include the ASIO files, automake switches to g++. So we need to force
portaudio to always be built using gcc. Anyone have any ideas
there?
.hc
.hc
On Jul 2, 2011, at 7:01 AM, Patrice Colet wrote:
I've found the odd part of that page is that they use
LTLIBRARIES
variable while pd/src/Makefile.am doesn't.
> On Fri, 01 Jul 2011 19:36 +0200, "IOhannes m zmölnig" >> On 07/01/2011 06:24 PM, Hans-Christoph Steiner wrote: >>> >>>> the trick to use g++ for linking, is to use a dummy .cpp
file,
> so >>>> autotools will automatically choose g++. >>>> >>>> something like: >>>> <snip> >>>> nodist_EXTRA_pd_SOURCES= >>>> if PORTAUDIO >>>> nodist_EXTRA_pd_SOURCES += dummy.cpp >>>> endif >>>> </snip> >>> >>> It would be worth trying: >>> >>> LD=$CXX >>> >> >> >
http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Li...
> > That solution at the bottom of that page looks easy but a bit
odd.
I
> suppose its the 'official' way. Patco, do you think you can
try
to
> get > that working? > > .hc > > _______________________________________________ > Pd-dev mailing list > Pd-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev
-- Patrice Colet
Mistrust authority - promote decentralization. - the hacker
ethic
-- Patrice Colet
Programs should be written for people to read, and only
incidentally
for machines to execute.
- from Structure and Interpretation of Computer Programs
-- Patrice Colet
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-05 18:02, Hans-Christoph Steiner wrote:
Hmm, that sounds like progress. Perhaps removing CC=g++ and then adding something like this would work:
if ASIO EXTRA_SUBDIRS += asio # automake hack to force linking with g++ lib_LTLIBRARIES = libdummy.la libdummy_la_SOURCES = # Dummy C++ source to cause C++ linking. nodist_EXTRA_libdummy_la_SOURCES = dummy.cxx endif
hmm, no this shouldn't work at all. it only tells automake to also build an additional (dummy) c++-library if ASIO was defined. it won't affect linking of pd at all (libdummy is not linked agains pd). if it does succeed, than i would suggest to report a bug agains automake...
fgmadr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-05 13:04, Patrice Colet wrote:
I've removed this in configure.ac:
# ASIO is a C++ library, so if its included, then use g++ to build CC=g++
compiles fine, only pd.exe is not working but pd.dll is fine, everything is built.
from all I've read in gnu manuals, automake automatically set g++ for cpp files so there is no need to set CC.
this what i have been suggesting (i think)
attached is a diff against upstreams Pd that should use g++ for linking when using ASIO (it might use g++ for all linking, but that should be ok as well), by letting automake choose (rather than forcing it to use a special linker like "g++" (which hardcodes the compiler name...uähh))
it works on linux :-)
fmgasdr IOhannes
On Jul 11, 2011, at 5:08 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-05 13:04, Patrice Colet wrote:
I've removed this in configure.ac:
# ASIO is a C++ library, so if its included, then use g++ to build CC=g++
compiles fine, only pd.exe is not working but pd.dll is fine, everything is built.
from all I've read in gnu manuals, automake automatically set g++ for cpp files so there is no need to set CC.
this what i have been suggesting (i think)
attached is a diff against upstreams Pd that should use g++ for linking when using ASIO (it might use g++ for all linking, but that should be ok as well), by letting automake choose (rather than forcing it to use a special linker like "g++" (which hardcodes the compiler name...uähh))
it works on linux :-)
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.
.hc
----------------------------------------------------------------------------
Mistrust authority - promote decentralization. - the hacker ethic
-----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
The problem I'm encountering on win32 with makefile.am is that pd.dll is not built
----- "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" 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' <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
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
<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.
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-11 19:37, Hans-Christoph Steiner wrote:
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:
shouldn't it be more like trying all available dylib loading mechanisms? e.g. if HAVE_LIBDL than try using dlopen, if that fails fall back to the w32 native LoadLibrary.
and finally, Pd should probably still be able to compile even if no dylib mechanism is present (think iOS). if the system cannot loading libraries, than Pd won't be able to load externals, but internals and abstractions will continue to work.
fgamsdr IOhannes
On Tue, 12 Jul 2011 09:22 +0200, "IOhannes m zmoelnig" zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-11 19:37, Hans-Christoph Steiner wrote:
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:
shouldn't it be more like trying all available dylib loading mechanisms? e.g. if HAVE_LIBDL than try using dlopen, if that fails fall back to the w32 native LoadLibrary.
and finally, Pd should probably still be able to compile even if no dylib mechanism is present (think iOS). if the system cannot loading libraries, than Pd won't be able to load externals, but internals and abstractions will continue to work.
Yes, defiitely. Here's how I am thinking (also attached):
--- a/src/s_loader.c +++ b/src/s_loader.c @@ -178,8 +178,7 @@ gotone: } 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) @@ -189,6 +188,8 @@ gotone: return (0); } makeout = (t_xxx)GetProcAddress(ntdll, symname); +#else +# warning "No dynamic loading mechanism specified, libdl or WIN32 required for loading externa #endif
if (!makeout)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/12/2011 10:18 PM, Hans-Christoph Steiner wrote:
+#else +# warning "No dynamic loading mechanism specified, libdl or WIN32 required for loading externa #endif
"#warning" is a gcc extension, so it's not very portable.
btw, "#error" is as well, but since other compilers will bail out with an error (for not understanding #error), the effect is similar to that in gcc)
fgmasdr IOhannes
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Patrice Colet