So in the auto-builds, the FTGL part of configure gives this error:
checking linux/videodev.h usability... no checking linux/videodev.h presence... no checking for linux/videodev.h... no ./configure: line 8733: pkg-config: command not found checking for PKG_FTGL_CFLAGS... checking for PKG_FTGL_LIBS... checking for ftgl-config... yes checking for main in -lftgl... no
When I run the build from a login shell, it works fine:
checking linux/videodev.h usability... no checking linux/videodev.h presence... no checking for linux/videodev.h... no checking whether linker accepts "-L/sw/lib/freetype219/lib -L/sw/lib - lz -lfreetype -lftgl_pic "... no checking for PKG_FTGL_CFLAGS... -I/sw/include -I/sw/include/FTGL -I/ sw/lib/freetype219/include -I/sw/lib/freetype219/include/freetype2 checking for PKG_FTGL_LIBS... -L/sw/lib/freetype219/lib -L/sw/lib -lz -lfreetype -lftgl
I think I found the source of the problem. My guess is that the Gem autoconf system relies on the environment's path. From my experience, all of the needed environment variables should be included in configure.ac so that the configure will. In this case pkg-config is in /sw/bin/pkg-config (Mac OS X does not include pkg- config). If a line something like this was added near the top of configure.ac, I think it would work:
PATH="${PATH}:/sw/bin"
.hc
------------------------------------------------------------------------ ----
Hans-Christoph Steiner wrote:
So in the auto-builds, the FTGL part of configure gives this error:
checking linux/videodev.h usability... no checking linux/videodev.h presence... no checking for linux/videodev.h... no ./configure: line 8733: pkg-config: command not found checking for PKG_FTGL_CFLAGS... checking for PKG_FTGL_LIBS... checking for ftgl-config... yes checking for main in -lftgl... no
When I run the build from a login shell, it works fine:
I think I found the source of the problem. My guess is that the Gem autoconf system relies on the environment's path. From my experience, all of the needed environment variables should be included in configure.ac so that the configure will. In this case pkg-config is in /sw/bin/pkg-config (Mac OS X does not include pkg- config). If a line something like this was added near the top of configure.ac, I think it would work:
PATH="${PATH}:/sw/bin"
i don't know;
does the ftgl-package provide pkg-config files for ftgl at all? (don't worry if not)
Gem uses pkg-config if it can find it; if it doesn't find pkg-config, it will try to use <package>-config (e.g. "ftgl-config"); if this fails too it will use defaults or at least respect the PKG_<package>_(CFLAG|LIB)S
nevertheless, it is interesting why the configure finds "ftgl-config" but still fails to load ftgl. (i guess linking against libftgl fails because configure doesn't automatically link against freetype2 too if not told (e.g. by ftgl-config).
i don't think it is a good idea to add arbitrary paths to configure.ac (but i will have to read the literature on how to handle this)
mfg.asdr IOhannes
On Jun 1, 2007, at 11:13 AM, IOhannes m zmölnig wrote:
Hans-Christoph Steiner wrote:
So in the auto-builds, the FTGL part of configure gives this error: checking linux/videodev.h usability... no checking linux/videodev.h presence... no checking for linux/videodev.h... no ./configure: line 8733: pkg-config: command not found checking for PKG_FTGL_CFLAGS... checking for PKG_FTGL_LIBS... checking for ftgl-config... yes checking for main in -lftgl... no When I run the build from a login shell, it works fine:
I think I found the source of the problem. My guess is that the Gem autoconf system relies on the environment's path. From my experience, all of the needed environment variables should be included in configure.ac so that the configure will. In this case pkg-config is in /sw/bin/pkg-config (Mac OS X does not include pkg- config). If a line something like this was added near the top of configure.ac, I think it would work: PATH="${PATH}:/sw/bin"
i don't know;
does the ftgl-package provide pkg-config files for ftgl at all? (don't worry if not)
Gem uses pkg-config if it can find it; if it doesn't find pkg- config, it will try to use <package>-config (e.g. "ftgl-config"); if this fails too it will use defaults or at least respect the PKG_<package>_(CFLAG|LIB)S
nevertheless, it is interesting why the configure finds "ftgl- config" but still fails to load ftgl. (i guess linking against libftgl fails because configure doesn't automatically link against freetype2 too if not told (e.g. by ftgl-config).
FTGL is built using xcode on Mac OS X, so there is not autoconf to make a ftgl-config or ftgl.pc. I hacked together a ftgl.pc in the Fink package, so that's what it's using when it builds successfully from a login shell. There is no ftgl-config in the fink package.
"pkg-config --cflags ftgl" and "pkg-config --libs ftgl" both work as long as /sw/bin is in the path, so that pkg-config can be found.
i don't think it is a good idea to add arbitrary paths to configure.ac (but i will have to read the literature on how to handle this)
I am pretty sure that literally adding this line to somewhere near the top of configure.ac will do it:
PATH="${PATH}:/sw/bin"
.hc
mfg.asdr IOhannes
------------------------------------------------------------------------ ----
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
hi
Quoting Hans-Christoph Steiner hans@eds.org:
FTGL is built using xcode on Mac OS X, so there is not autoconf to make a ftgl-config or ftgl.pc. I hacked together a ftgl.pc in the Fink package, so that's what it's using when it builds successfully from a login shell. There is no ftgl-config in the fink package.
"pkg-config --cflags ftgl" and "pkg-config --libs ftgl" both work as long as /sw/bin is in the path, so that pkg-config can be found.
thanks for the clarification.
i don't think it is a good idea to add arbitrary paths to configure.ac (but i will have to read the literature on how to handle this)
I am pretty sure that literally adding this line to somewhere near the top of configure.ac will do it:
PATH="${PATH}:/sw/bin"
i do not doubt that this is correct. otoh, i could also do something like PATH="${PATH}:$(find / -type d -exec echo -n {}: ;)" will make it work.
i am sure that the latter is a bad idea, and i do think that the your solution is not much better: adding arbitrary paths to a script like configure might be fatal.
in the meantime you could set configure's path explicitely from outside:
PATH=${PATH}:/bin/sw ./configure
or even better: set the path for the entire make-process of pd-extended:
cd /bi/ba/bo/pd-extended/puredata/packages PATH=${PATH}:/bin/sw make
mfg.asdr IOhannes
On Jun 3, 2007, at 5:46 AM, zmoelnig@iem.at wrote:
hi
Quoting Hans-Christoph Steiner hans@eds.org:
FTGL is built using xcode on Mac OS X, so there is not autoconf to make a ftgl-config or ftgl.pc. I hacked together a ftgl.pc in the Fink package, so that's what it's using when it builds successfully from a login shell. There is no ftgl-config in the fink package.
"pkg-config --cflags ftgl" and "pkg-config --libs ftgl" both work as long as /sw/bin is in the path, so that pkg-config can be found.
thanks for the clarification.
i don't think it is a good idea to add arbitrary paths to configure.ac (but i will have to read the literature on how to handle this)
I am pretty sure that literally adding this line to somewhere near the top of configure.ac will do it:
PATH="${PATH}:/sw/bin"
i do not doubt that this is correct. otoh, i could also do something like PATH="${PATH}:$(find / -type d -exec echo -n {}: ;)" will make it work.
i am sure that the latter is a bad idea, and i do think that the your solution is not much better: adding arbitrary paths to a script like configure might be fatal.
in the meantime you could set configure's path explicitely from outside:
PATH=${PATH}:/bin/sw ./configure
or even better: set the path for the entire make-process of pd- extended:
cd /bi/ba/bo/pd-extended/puredata/packages PATH=${PATH}:/bin/sw make
I did this in externals/pidip/configure.ac and it works well:
# Check for DarwinPorts and/or Fink on Mac OS X/Darwin case "$host" in *-darwin* | *-macos10*) if test -d /sw ; then # Fink PATH="/sw/bin:/sw/sbin:$PATH" CFLAGS="$CFLAGS -I/sw/include" CPPFLAGS="$CPPFLAGS -I/sw/include" LDFLAGS="$LDFLAGS -L/sw/lib" elif test -d /opt/local ; then # DarwinPorts PATH="/opt/local/bin:/opt/local/sbin:$PATH" CFLAGS="$CFLAGS -I/opt/local/include" CPPFLAGS="$CPPFLAGS -I/opt/local/include" LDFLAGS="$LDFLAGS -L/opt/local/lib" fi ;; esac
I took this snippet from another project's configure.ac, I think it's a common and sensible way of handling Fink and DarwinPorts. As you have said before, the Gem build system aims to build Gem using what is installed on that machine. This would definitely help that process, people wouldn't have to know how to setup their environment in order for the Gem build to use Fink and/or DarwinPorts.
.hc
mfg.asdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
------------------------------------------------------------------------ ----
Hans-Christoph Steiner wrote:
I took this snippet from another project's configure.ac, I think it's a common and sensible way of handling Fink and DarwinPorts. As you have said before, the Gem build system aims to build Gem using what is installed on that machine. This would definitely help that process, people wouldn't have to know how to setup their environment in order for the Gem build to use Fink and/or DarwinPorts.
i thought the paths were found fine when running the configure by hand. i thought this problem only occurs with autobuild (e.g. cron-triggered) systems?
nevertheless, i will investigate...
mfa.sdr IOhannes
On Jun 4, 2007, at 3:14 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I took this snippet from another project's configure.ac, I think it's a common and sensible way of handling Fink and DarwinPorts. As you have said before, the Gem build system aims to build Gem using what is installed on that machine. This would definitely help that process, people wouldn't have to know how to setup their environment in order for the Gem build to use Fink and/or DarwinPorts.
i thought the paths were found fine when running the configure by hand. i thought this problem only occurs with autobuild (e.g. cron- triggered) systems?
nevertheless, i will investigate...
If a person has set up their PATH in their environment to use Fink/ DarwinPorts, then Gem's ./configure will use it, just like any other program that inherits env vars from the shell.
But if someone has installed Fink/DarwinPorts, but did not setup their shell's PATH, then Gem's configure would not find the things. That's what that chunk does, make sure ./configure will find stuff there.
I think it's pretty safe, it's just adding paths to the PATH variable.
.hc
mfa.sdr IOhannes
------------------------------------------------------------------------ ----
All information should be free. - the hacker ethic
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
zmoelnig＠iem.at