"unable to infer tagged configuration" when trying to build apache2 is already filed: http://trac.macosforge.org/projects/macports/ticket/13653 Someone also filed it for mjpegtools: http://trac.macosforge.org/projects/macports/ticket/13648 Both tickets include lots of discussion. The apache2 ticket includes patches which someone said worked. Neither maintainer has responded to the tickets. Looks like it's time for someone else to commit the fixes. Probably not me, since I'm not experiencing the issue. On Jan 31, 2008, at 18:34, paul beard wrote:

Looks like I have some problem with libtool. libIDL and Apache2 both fail to upgrade.

---> Building apache2 with target all Error: Target org.macports.build returned: shell command " cd "/opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_www_a pache2/work/httpd-2.2.8" && make all " returned error 2 Command output: Making all in srclib Making all in os Making all in unix /opt/local/share/apr-1/build/libtool --silent --mode=compile /usr/ bin/gcc-4.0 -I/opt/local/include -O2 -DDARWIN - DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -I/opt/local/ include -I. -I/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_www_a pache2/work/httpd-2.2.8/os/unix -I/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_www_a pache2/work/httpd-2.2.8/server/mpm/prefork -I/opt/local/var/ macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_www_a pache2/work/httpd-2.2.8/modules/http -I/opt/local/var/macports/ build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_www_a pache2/work/httpd-2.2.8/modules/filters -I/opt/local/var/macports/ build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_www_a pache2/work/httpd-2.2.8/modules/proxy -I/opt/local/var/macports/ build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_www_a pache2/work/httpd-2.2.8/include -I/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_www_a pache2/work/httpd-2.2.8/modules/generators -I/opt/local/var/ macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_www_a pache2/work/httpd-2.2.8/modules/mappers -I/opt/local/var/macports/ build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_www_a pache2/work/httpd-2.2.8/modules/database -I/opt/local/include/apr-1 -I/opt/local/include -I/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_www_a pache2/work/httpd-2.2.8/server -I/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_www_a pache2/work/httpd-2.2.8/modules/proxy/../generators -I/opt/local/ var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_www_a pache2/work/httpd-2.2.8/modules/ssl -I/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_www_a pache2/work/httpd-2.2.8/modules/dav/main -prefer-non-pic -static - c unixd.c && touch unixd.lo libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' make[3]: *** [unixd.lo] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1

On Feb 3, 2008, at 03:32, Anders F Björklund wrote:

paul beard wrote:

...

Looks like I have some problem with libtool. libIDL and Apache2 both fail to upgrade. ... libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag'

This problem is since the change to "/usr/bin/gcc-4.0" for CC. Switching compiler back to "gcc" (or "gcc-4.0") makes it work.

Something like: port build configure.cc=gcc configure.cxx=g++

Can you explain more? Isn't "gcc" the same as "/usr/bin/gcc" which is a symlink to "/usr/bin/gcc-4.0"? Also, I do not experience this problem with apache2; why would some people see it and not others?

We also have some ports that break when using ccache(*), those can be made to work by using configure.ccache=no when building.

* http://ccache.samba.org/

On Feb 3, 2008 8:29 AM, Anders F Björklund <afb@macports.org> wrote:

Rebuilding libtool might also work, haven't tried that either.

I have. It doesn't help. How do you use the configure args you posted? Just on the commandline? -- Paul Beard / www.paulbeard.org/ <paulbeard@gmail.com/paulbeard@gmail.com>

paul beard wrote:

On Feb 3, 2008 1:32 AM, Anders F Björklund <afb@macports.org <mailto:afb@macports.org>> wrote:

paul beard wrote:

> Looks like I have some problem with libtool. > libIDL and Apache2 both fail to upgrade. ... > libtool: compile: unable to infer tagged configuration > libtool: compile: specify a tag with `--tag'

This problem is since the change to "/usr/bin/gcc-4.0" for CC. Switching compiler back to "gcc" (or "gcc-4.0") makes it work.

what baffles me about this is that the libtool that's being invoked is part of the port's code:

/bin/sh ./libtool --tag=CC --mode=link gcc -O2 -no-cpp-precomp -version-info 0:0:0 -L/opt/local/lib -lglib-2.0 -lintl -liconv -no-undefined -L/opt/local/lib -o libIDL-2.la -rpath /opt/local/lib parser.lo lexer.lo ns.lo util.lo

if I run port configure (with -d), what's happening here?

configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by /usr/bin/g++-4.0... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the /usr/bin/g++-4.0 linker (/usr/bin/ld) supports shared libraries... yes

libtool is usually built in the build directory by running configure, it is included in the package. I had a quick look at the bugs mentioned: http://trac.macosforge.org/projects/macports/ticket/13653 http://trac.macosforge.org/projects/macports/ticket/13648 In both cases an installed GNU libtool is being called with a different compiler (at least a different compiler name) than it was built with. In these cases the tag *must* be specified --tag=CC or --tag=CXX etc. as GNU libtool can not guess it. Use the CC tag for C sources and the CXX tag for c++. For automake based projects automake adds the --tag when compiling with gnu libtool, for other projects upstream developer should be adding it, please send them patches. Peter -- Peter O'Gorman http://pogma.com

Ryan Schmidt wrote:

...

...

what baffles me about this is that the libtool that's being invoked is part of the port's code:

/bin/sh ./libtool --tag=CC --mode=link gcc -O2 -no-cpp-precomp -version-info 0:0:0 -L/opt/local/lib -lglib-2.0 -lintl -liconv -no-undefined -L/opt/local/lib -o libIDL-2.la -rpath /opt/local/lib parser.lo lexer.lo ns.lo util.lo

This is failing with 'unable to infer tagged configuration'? Seems pretty strange as it has a --tag argument, it should not even be trying to infer the tag.

...

...

if I run port configure (with -d), what's happening here?

configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by /usr/bin/g++-4.0... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the /usr/bin/g++-4.0 linker (/usr/bin/ld) supports shared libraries... yes

libtool is usually built in the build directory by running configure, it is included in the package. I had a quick look at the bugs mentioned:

http://trac.macosforge.org/projects/macports/ticket/13653 http://trac.macosforge.org/projects/macports/ticket/13648

In both cases an installed GNU libtool

which installed GNU libtool? you mean the libtool that the project built for itself?

one is calling /opt/local/bin/glibtool, the other is using apr's libtool (/opt/local/share/apr-1/build/libtool).

...

is being called with a different compiler (at least a different compiler name) than it was built with.

what compiler name was it built with, and what compiler name is it being called with? and why are they different?

I assume it was built with 'gcc' and it is being called with '/usr/bin/gcc-4.0'. Not the same name. Peter -- Peter O'Gorman http://pogma.com

On 2008-02-03 , at 13:03 , Ryan Schmidt wrote:

Maybe the problem is that the users experiencing this problem installed either libtool or apr or both before MacPorts 1.6 and are now trying to install apache2 with MacPorts 1.6? Could that be? If so the solution would be to rebuild libtool or apr?

sudo port -f uninstall libtool sudo port -f uninstall apr sudo port install libtool sudo port install apr sudo port clean apache2 sudo port upgrade apache2 Solved the problem for me on my 10.4 Intel system - no more build errors. I will do the same on my 10.5 system and report back if it fails. 8) ---------------------------------- Chris Janton - face at CentosPrime dot COM Netminder for Opus1.COM

On Feb 3, 2008 1:24 PM, David Epstein <David.Epstein@warwick.ac.uk> wrote:

Ryan Schmidt-24 wrote:

...

"unable to infer tagged configuration" when trying to build apache2 is already filed: http://trac.macosforge.org/projects/macports/ticket/13653 ...[snip]... Both tickets include lots of discussion. The apache2 ticket includes patches which someone said worked. Neither maintainer has responded to the tickets. Looks like it's time for someone else to commit the fixes. Probably not me, since I'm not experiencing the issue.

As an inexperienced MacPorter, I would like advice on what to do, in view of my need for apache2. Possible strategies: 1) Wait for someone to put the advertised patches into the official macport distribution. 2) Install the advertised patches. (Are there instructions somewhere for how to do this?) 3) Try rebuilding libtool. (But won't port object to deleting libtool because other packages depend on it?)

I am trying this regime: sudo port -f uninstall libtool sudo port -f uninstall apr sudo port install libtool sudo port install apr sudo port clean apache2 sudo port upgrade apache2 port -f overrides any complaints (on your #3 above). if peter o'gorman's diagnosis above is correct, how can this be fixed in a more systematic manner? -- Paul Beard / www.paulbeard.org/ <paulbeard@gmail.com/paulbeard@gmail.com>

For anyone else who may be struggling with getting Oracle to play with MacPorts PHP, here are my notes after installation on three systems and about 100 hours of tinkering. Start with a PowerPC, as the Oracle Instant Client for Mac does not yet work with Intel machines. 1. Install php5 with oracle support: sudo port install php5 +apache2 +oracle 2. So that the Apache user can find the relevant files, add environment variables to opt/local/apache2/bin/envvars: export LD_LIBRARY_PATH="/opt/local/lib/oracle" export TNS_ADMIN="/Applications/Oracle" (or whatever folder is a convenient spot to store sqlnet.ora and tnsnames.ora) Many web sites refer to setting DYLD_LIBRARY_PATH, you can do that instead of LD_LIBRARY_PATH and it has the same effect. Heck, use 'em both for good measure! Do _not_ use putenv in a PHP script or SetEnv in httpd.conf to set the variables, it won't work. Apache will also not pick up environment variables from /private/etc/profile. Note to Ryan: can MacPorts update envvars? 3. Restart Apache For testing purposes, you can also add support for SQLPlus from the command line by downloading the Instant Client SQLPlus files from http://www.oracle.com/technology/software/tech/oci/instantclient/htdocs/macs oft.html and copying them to opt/local/lib/oracle. In that case you will have to add these variables to /Users/YourUserName/.profile: export LD_LIBRARY_PATH="/opt/local/lib/oracle:$LD_LIBRARY_PATH" export TNS_ADMIN="/Applications/Oracle" export PATH="/opt/local/lib/oracle:$PATH" If you prefer all users to have SQLPlus access, add the variables to /private/etc/profile If you have trouble with errors like "ORA-12154: TNS:could not resolve the connect identifier specified", Oracle may not be able to read your tnsnames.ora file. We had to amend the first line from "ALIG" to "ALIG.revion.com" (appending the url of the host name) to get it to work. Here are connection strings for PHP and SQLPlus, respectively: $con = OCILogon('YourUserName', 'YourPassword', "//your.host.address.com:1521/YourServiceName"); sqlplus YourUserName/YourPassword@//your.host.address.com:1521/YourServiceName If all else fails, you can use a verbose connection string to eliminate any need for tnsnames.ora: $con = oci_connect('YourUserName', 'YourPassword', '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=your.host.address.com)(PORT=1521) )(CONNECT_DATA=(SID=YourServiceName)(SERVER=DEDICATED)))'); Here's the verbose syntax for SQLPlus: sqlplus YourUserName/YourPassword@\(DESCRIPTION=\(ADDRESS=\(PROTOCOL=TCP\)\(HOST=you r.host.address.com\)\(PORT=1521\)\)\(CONNECT_DATA=\(SID=YourServiceName\)\(S ERVER=DEDICATED\)\)\) John Korchok

Ryan Schmidt wrote:

...

...

...

libtool is usually built in the build directory by running configure, it is included in the package. I had a quick look at the bugs mentioned:

http://trac.macosforge.org/projects/macports/ticket/13653 http://trac.macosforge.org/projects/macports/ticket/13648

In both cases an installed GNU libtool

which installed GNU libtool? you mean the libtool that the project built for itself?

one is calling /opt/local/bin/glibtool, the other is using apr's libtool (/opt/local/share/apr-1/build/libtool).

I don't know what "one" or "the other" is.

That's silly - I listed the 2 bugs, two builds, "one" and "the other". But now you're saying there

are three libtools involved -- the one in /opt/local/bin/glibtool, the one in /opt/local/share/apr-1/build/libtool, and the one in ${worksrcdir}/libtool?

I have the libtool port installed and do not see the problem. Maybe I would see the problem if I removed the libtool port?

From the looks of things MacPorts at some point changed the default setting for CC?

If that is the case, it means that people who had built e.g. apr before it was changed, and then tried to build apache after the change will see this breakage. Peter -- Peter O'Gorman http://pogma.com

On Feb 4, 2008, at 02:02, David Epstein wrote:

Paul Beard-2 wrote:

...

I am trying this regime:

sudo port -f uninstall libtool sudo port -f uninstall apr sudo port install libtool sudo port install apr sudo port clean apache2 sudo port upgrade apache2

port -f overrides any complaints

This worked for me on Mac Os X 10.4.11, MacPorts 1.600. I include the initial response of port, which shows something, I'm not sure what. When I originally tried to install apache2, port made no attempt to install libtool. Isn't this surprising in view of the first line of the log below? So it seems that apache2 does not list its dependencies correctly, which would explain why everything is fine for some users but not for others. Or maybe the problem is that there are different versions of libtool, as mentioned previously in this thread---I'm not sure if this makes sense. Anyway, here is the initial output from Paul Beard's commands:

Error: port uninstall failed: Registry error: libtool not registered as installed. ---> Unable to uninstall apr 1.2.11_0, the following ports depend on it: ---> apr-util ---> subversion Warning: Uninstall forced. Proceeding despite dependencies. ---> Deactivating apr 1.2.11_0 ---> Uninstalling apr 1.2.11_0 ---> Fetching libtool ---> Attempting to fetch libtool-1.5.24.tar.gz fromhttp://ftp.gnu.org/gnu/libtool ---> Verifying checksum(s) for libtool ---> Extracting libtool ---> Configuring libtool---> Building libtool with target all ---> Staging libtool into destroot ---> Installing libtool 1.5.24_1 ---> Activating libtool 1.5.24_1---> Cleaning libtool

So based on the fact that you experienced the error without libtool installed, and that Peter O'Gorman says it may be that apr was built before MacPorts 1.6 was released, it sounds like maybe apr, and not libtool, was the problem. I originally suggested that one or the other of those ports was the problem but I have yet to hear anyone definitively say which one it is. Simply force-upgrading both doesn't help us isolate the problem. :) I note that in your output above, you're uninstalling apr 1.2.11_0. That's an old version anyway. The current version is 1.2.12_0. So you should try uninstalling libtool, then upgrading apr, then see if it works.