libtool woes

[Paul Beard-2]

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_apache2/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_apache2/work/httpd-2.2.8/os/unix -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_apache2/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_apache2/work/httpd-2.2.8/modules/http -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_apache2/work/httpd-2.2.8/modules/filters -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_apache2/work/httpd-2.2.8/modules/proxy -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_apache2/work/httpd-2.2.8/include -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_apache2/work/httpd-2.2.8/modules/generators -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_apache2/work/httpd-2.2.8/modules/mappers -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_apache2/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_apache2/work/httpd-2.2.8/server -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_apache2/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_apache2/work/httpd-2.2.8/modules/ssl -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_apache2/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

--
Paul Beard / www.paulbeard.org/
<paulbeard@.../paulbeard@...>

_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users

[Ryan Schmidt-24]

"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

_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users

[Anders F Björklund-2]

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++

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/

--anders

_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users

[Ryan Schmidt-24]

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/

_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users

[Anders F Björklund-2]

Ryan Schmidt wrote:

>> 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?

It's the exact same thing, just that some versions of libtool
weren't able to determine what to do with "/usr/bin/gcc-4.0"

Haven't yet checked which ports the issue affects, and which
are hit by something else - but it would be something to check...

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

--anders

_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users

[Paul Beard-2]

On Feb 3, 2008 8:29 AM, Anders F Björklund <afb@...> 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@.../paulbeard@...>
_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users

[Paul Beard-2]

On Feb 3, 2008 1:32 AM, Anders F Björklund <afb@...> 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

--
Paul Beard / www.paulbeard.org/
<paulbeard@.../paulbeard@...>

_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users

[Peter O'Gorman]

paul beard wrote:

>
>
> On Feb 3, 2008 1:32 AM, Anders F Björklund <afb@...
> <mailto:afb@...>> 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
_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users

[Ryan Schmidt-24]

On Feb 3, 2008, at 13:27, Peter O'Gorman wrote:

> paul beard wrote:
>
>> On Feb 3, 2008 1:32 AM, 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.
>>
>> 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

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

> 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?

> 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.

_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users

[Peter O'Gorman]

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
_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users

[Ryan Schmidt-24]

On Feb 3, 2008, at 13:50, Peter O'Gorman wrote:

> 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.

I don't know what's going on; I'm just quoting here.

>>>> 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).

I don't know what "one" or "the other" is. 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?

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?

>>> 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.

_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users

[Chris Janton]

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


_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users

[David Epstein]

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?)

Pointer to relevant online advice??
David

[Paul Beard-2]

On Feb 3, 2008 1:24 PM, David Epstein <David.Epstein@...> 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@.../paulbeard@...>

_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users

[Ryan Schmidt-24]

On Feb 3, 2008, at 15:09, Chris Janton wrote:

> 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.

Good to know!

> I will do the same on my 10.5 system and report back if it fails.

Can you try just libtool first? Then if that fails, then try apr.

_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users

[John Korchok]

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

_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users

[Chris Janton]

On 2008-02-03 , at 14:33 , paul beard 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


This worked on my 10.5 system where I had the apache2 problem as well.

8)
----------------------------------
Chris Janton  - face at CentosPrime dot COM
Netminder for Opus1.COM


_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users

[Peter O'Gorman]

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
_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users

[David Epstein]

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

[Ryan Schmidt-24]

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.


_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users