Re: Solaris and socket library

2004-01-16 Thread jling
Thank you for sharing your configuration.  I will definitely look more 
closely at these macros.

John Ling

- Original Message -
From: Russ Allbery <[EMAIL PROTECTED]>
Date: Friday, January 16, 2004 6:55 pm
Subject: Re: Solaris and socket library

> John Ling <[EMAIL PROTECTED]> writes:
> 
> > Now the solution was to add a -lsocket to the linking options.  But,
> > should this not be something that autoconf or automake suite of 
> tools> detect and automatically handle for me?  Do I need to 
> manually add this
> > only when I run on Solaris?
> 
> I use this:
> 
> dnl The rat's nest of networking libraries.  The common cases are 
> not to
> dnl need any extra libraries, or to need -lsocket -lnsl.  We need 
> to avoid
> dnl linking with libnsl unless we need it, though, since on some 
> OSes where
> dnl it isn't necessary it will totally break networking.  Unisys also
> dnl includes gethostbyname in libsocket but needs libnsl for socket().
> AC_SEARCH_LIBS([gethostbyname], [nsl])
> AC_SEARCH_LIBS([socket], [socket], ,
>[AC_CHECK_LIB([nsl], [socket], LIBS="$LIBS -lsocket -lnsl", , -
> lsocket)])
> in configure.ac.
> 
> -- 
> Russ Allbery ([EMAIL PROTECTED]) <" 
> target="l">http://www.eyrie.org/~eagle/>
> 
> 





Re: Solaris and socket library

2004-01-16 Thread jling
Thank you Bob for that very useful bit of knowledge.

John Ling


- Original Message -
From: Bob Friesenhahn <[EMAIL PROTECTED]>
Date: Friday, January 16, 2004 5:14 pm
Subject: Re: Solaris and socket library

> This is an Autoconf issue, not Automake.  Adding the following 
> line to
> your configure.ac file will likely resolve the problem:
> 
>  AC_SEARCH_LIBS([connect],[socket],[],[],[])
> 
> It should add -lsocket to LIBS if necessary.
> 
> Bob
> 
> On Fri, 16 Jan 2004, John Ling wrote:
> 
> > I am running on Solaris and I was trying to compile an 
> application that
> > used the libmysqlclient.a library.
> >
> > I encountered an error:
> >
> > Undefined   first referenced
> >  symbol in file
> > socket
> > /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o)
> > getpeername
> > /usr/local/mysql4/lib/libmysqlclient.a(viosocket.o)
> > setsockopt
> > /usr/local/mysql4/lib/libmysqlclient.a(viosocket.o)
> > getservbyname
> > /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o)
> > getsockopt
> > /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o)
> > shutdown
> > /usr/local/mysql4/lib/libmysqlclient.a(viosocket.o)
> > connect
> > /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o)
> > ld: fatal: Symbol referencing errors.
> >
> >
> > Now the solution was to add a -lsocket to the linking options.
> > But, should this not be something that autoconf or automake 
> suite of
> > tools detect and automatically handle for me?  Do I need to 
> manually add
> > this only when I run on Solaris?
> >
> > Now that I do need to handle this.  Where is the best place to 
> check the
> > OS environment variable to see if I need to set this as a variable
> > somewhere.  I wanted to do something like:
> >
> > ifeq ($(OSTYPE),solaris)
> >   export SOCKET = -lsocket
> > endif
> >
> > Do I do this in configure.in somehow or in Makefile.am?  Is 
> there a
> > better way anyone can suggest.  I would think something like 
> this is a
> > common problem to handle.
> >
> > Thanks,
> > John Ling
> >
> >
> >
> 
> ==
> Bob Friesenhahn
> [EMAIL PROTECTED]
> http://www.simplesystems.org/users/bfriesen
> 
> 
> 
> 





Re: Solaris and socket library

2004-01-16 Thread Russ Allbery
John Ling <[EMAIL PROTECTED]> writes:

> Now the solution was to add a -lsocket to the linking options.  But,
> should this not be something that autoconf or automake suite of tools
> detect and automatically handle for me?  Do I need to manually add this
> only when I run on Solaris?

I use this:

dnl The rat's nest of networking libraries.  The common cases are not to
dnl need any extra libraries, or to need -lsocket -lnsl.  We need to avoid
dnl linking with libnsl unless we need it, though, since on some OSes where
dnl it isn't necessary it will totally break networking.  Unisys also
dnl includes gethostbyname in libsocket but needs libnsl for socket().
AC_SEARCH_LIBS([gethostbyname], [nsl])
AC_SEARCH_LIBS([socket], [socket], ,
[AC_CHECK_LIB([nsl], [socket], LIBS="$LIBS -lsocket -lnsl", , -lsocket)])

in configure.ac.

-- 
Russ Allbery ([EMAIL PROTECTED]) 




Re: utility programs used during build

2004-01-16 Thread Ralf Corsepius
On Fri, 2004-01-16 at 21:00, Tom Tromey wrote:
> > "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
> 
> >> > If you want a clean way, you'd have to split buildtools and
> >> > host-packages into separate (sub) packages and write a costomized
> >> > toplevel configure-script to parse and set the configure options for
> >> > build- and host- compile packages.
> 
> Ralf> This is the current nominal working principle, as it is applied by
> Ralf> packages which actually support cross-compilation (gcc, newlib,
> Ralf> binutils, gdb etc.).
> 
> Hmm, I think we're mixing scenarios.
I don't think so.

> In gcc, for instance, ordinarily target libraries are put in their
> own directories with their own configuration.  And there is also a
> surrounding layer of hackery to deal with multilibs.
Yes, you are referring to $target_subdir

> But that isn't what Warren is talking about.  He's talking about a
> situation where you want to build your package for a different host,
> but first build some helper programs on the build machine to create
> other parts of your program.
That's exactly the situation each sub-package underneath the (gcc,
binutils, newlib, gdb) "ueberbaum" is facing.

Each of them requires to "build some helper programs on the build
machine, to create other parts of your program"

For instance, when building a cross-gcc one-tree style, 
* the cross-binutils (target-ar, target-ld etc.) are such helper
programs (They run on the build host).
* from the perspective/view of the lib*-packages in gcc's source-tree,
xgcc is such a tool.

> E.g., in gcc there are the gen* family of programs, like genattrtab.
> These are just incorporated in the gcc source directory along with
> files that will be compiled for the host machine, not the build
> machine.
Yes, these are set of tools inside of the source-tree, not applying the
approach I am talking about.

> My opinion on this is that total separation is easier to implement,
Agreed, I am convinced, that not applying the "split-package" approach
will be costly in longer terms.

[Have a look at gnatlib in gcc. The Ada-folks prefer to not split out
their sources and prefer to lump together gnatlib with the rest of gnat.
Consequence: in gcc-3.3.* gnatlib can't be cross-built properly (If it
does on a particular build system, it is just a random accident, because
build system and host system are similar enough for not causing
conflicts.)]

> but not really cleaner.  "Clean" depends on the needs of the package
> at hand, sometimes you'd really rather just lump all the sources
> together.
Well, I have been facing this issue myself. At first, it seems to be
annoying ("What do I really need to ... it's only one file, implementing
a little helper tool"), I had to learn it to pay off in longer terms.

> Alexandre's simple solution of overriding _CC and the like is nice.
That's not what I am referring to. I am referring to gcc's toplevel
configure script (The old "cygnus configure") and it's internal working
principle:

mkdir $target_subdir/$package
cd $target_subdir/$package;
CC=$CC_FOR_TARGET ... /$package/configure

This approach fits cleanly into the autoconf's working principles,
doesn't conflict with automake/libtool. 
All that lacks to make this handy basically is
"BUILD|HOST|TARGET_CONFIG_SUBDIR" support in autoconf and "make dist"
support in automake.

>   I
> think at least one part of this must be handled automatically,
s/must/should/, otherwise agreed
> and
> that is the selection of EXEEXT, which can differ between build and
> host.
ACK, but I am inclined regard even as an almost marginal special case.

IMO, the real problems are lurking in AC_TRY_COMPILE/LINK and AC_DEFINE
and everything based on them.

AC_TRY_COMPILE/LINK with the build or host compiler? Where to store
AC_DEFINEs, build or host CONFIG-header? And how to pass on INCLUDES,
LIBS, DEFS, CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS etc.?

For simple cases, falling back to manually written make-rules using a
handful of custom *_FOR_BUILD variables probably is the easiest way.

Even simplier to is avoid compilation at all and implement such tools in
a scripting language (This is what the fix*-tools/scripts in gcc do/did)

>   And really my preference would be to have it all done
> automatically, since that is easier for the user and less
> error-prone... still, it looks like the same internal mechanisms are
> necessary to support build compilers and per-target compilers.
> 
> Anyway, it looks like there's a big job ahead for Warren :-).
:-) Don't get me wrong, though it might sound as if, I am definitely not
wanting to discourage him nor anybody else.
It's just that I am fighting with autoconf/automake/libtools and their
application to cross-building for years and believe to be able to
estimate the problems/issues ahead :-)

Ralf






Re: Solaris and socket library

2004-01-16 Thread Bob Friesenhahn
This is an Autoconf issue, not Automake.  Adding the following line to
your configure.ac file will likely resolve the problem:

  AC_SEARCH_LIBS([connect],[socket],[],[],[])

It should add -lsocket to LIBS if necessary.

Bob

On Fri, 16 Jan 2004, John Ling wrote:

> I am running on Solaris and I was trying to compile an application that
> used the libmysqlclient.a library.
>
> I encountered an error:
>
> Undefined   first referenced
>  symbol in file
> socket
> /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o)
> getpeername
> /usr/local/mysql4/lib/libmysqlclient.a(viosocket.o)
> setsockopt
> /usr/local/mysql4/lib/libmysqlclient.a(viosocket.o)
> getservbyname
> /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o)
> getsockopt
> /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o)
> shutdown
> /usr/local/mysql4/lib/libmysqlclient.a(viosocket.o)
> connect
> /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o)
> ld: fatal: Symbol referencing errors.
>
>
> Now the solution was to add a -lsocket to the linking options.
> But, should this not be something that autoconf or automake suite of
> tools detect and automatically handle for me?  Do I need to manually add
> this only when I run on Solaris?
>
> Now that I do need to handle this.  Where is the best place to check the
> OS environment variable to see if I need to set this as a variable
> somewhere.  I wanted to do something like:
>
> ifeq ($(OSTYPE),solaris)
>   export SOCKET = -lsocket
> endif
>
> Do I do this in configure.in somehow or in Makefile.am?  Is there a
> better way anyone can suggest.  I would think something like this is a
> common problem to handle.
>
> Thanks,
> John Ling
>
>
>

==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen





Solaris and socket library

2004-01-16 Thread John Ling
I am running on Solaris and I was trying to compile an application that 
used the libmysqlclient.a library.

I encountered an error:

Undefined   first referenced
symbol in file
socket  
/usr/local/mysql4/lib/libmysqlclient.a(libmysql.o)
getpeername 
/usr/local/mysql4/lib/libmysqlclient.a(viosocket.o)
setsockopt  
/usr/local/mysql4/lib/libmysqlclient.a(viosocket.o)
getservbyname   
/usr/local/mysql4/lib/libmysqlclient.a(libmysql.o)
getsockopt  
/usr/local/mysql4/lib/libmysqlclient.a(libmysql.o)
shutdown
/usr/local/mysql4/lib/libmysqlclient.a(viosocket.o)
connect 
/usr/local/mysql4/lib/libmysqlclient.a(libmysql.o)
ld: fatal: Symbol referencing errors.

Now the solution was to add a -lsocket to the linking options.
But, should this not be something that autoconf or automake suite of 
tools detect and automatically handle for me?  Do I need to manually add 
this only when I run on Solaris?

Now that I do need to handle this.  Where is the best place to check the 
OS environment variable to see if I need to set this as a variable 
somewhere.  I wanted to do something like:

ifeq ($(OSTYPE),solaris)
 export SOCKET = -lsocket
endif
Do I do this in configure.in somehow or in Makefile.am?  Is there a 
better way anyone can suggest.  I would think something like this is a 
common problem to handle.

Thanks,
John Ling




Re: utility programs used during build

2004-01-16 Thread Tom Tromey
> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:

>> > If you want a clean way, you'd have to split buildtools and
>> > host-packages into separate (sub) packages and write a costomized
>> > toplevel configure-script to parse and set the configure options for
>> > build- and host- compile packages.

Ralf> This is the current nominal working principle, as it is applied by
Ralf> packages which actually support cross-compilation (gcc, newlib,
Ralf> binutils, gdb etc.).

Hmm, I think we're mixing scenarios.

In gcc, for instance, ordinarily target libraries are put in their
own directories with their own configuration.  And there is also a
surrounding layer of hackery to deal with multilibs.

But that isn't what Warren is talking about.  He's talking about a
situation where you want to build your package for a different host,
but first build some helper programs on the build machine to create
other parts of your program.

E.g., in gcc there are the gen* family of programs, like genattrtab.
These are just incorporated in the gcc source directory along with
files that will be compiled for the host machine, not the build
machine.


My opinion on this is that total separation is easier to implement,
but not really cleaner.  "Clean" depends on the needs of the package
at hand, sometimes you'd really rather just lump all the sources
together.


Alexandre's simple solution of overriding _CC and the like is nice.  I
think at least one part of this must be handled automatically, and
that is the selection of EXEEXT, which can differ between build and
host.  And really my preference would be to have it all done
automatically, since that is easier for the user and less
error-prone... still, it looks like the same internal mechanisms are
necessary to support build compilers and per-target compilers.

Anyway, it looks like there's a big job ahead for Warren :-).

Tom




Safe & Natural for the New Year

2004-01-16 Thread Ollie Cooper













Re: fortran FC patch

2004-01-16 Thread Norman Gray

Greetings,

In , Michael
Nolta offered a simple patch for `fc' support, and Alexandre's reply
suggested that there was unlikely to be a problem including this.

This appears not to be in the current CVS sources (on the head, after "cvs
-z 9 -d :pserver:[EMAIL PROTECTED]:/cvs/automake co automake").
Ought I to be surprised?  Am I looking in the right place?

I ask because I'm working just now on adding support to both autoconf
and automake to support preprocessing of Fortran 77, and it makes most
sense if I do so on top of the `fc' support rather than the older
`f77' support.

The preprocessing support is not mine, but Martin Wilck's (see [1]).
He submitted patches for this in 2000, but for some reason or another
they never made it into the autoconf or automake sources.  I'm just
adding them now, adjusting them so they're compatible with the current
autoconf and automake versions.

Given that there isn't a problem with Michael's patches, and given
that I don't _really_ want to muck about with the CVS head, would it
be reasonable for me to apply Michael's patches to a local copy of
automake 1.8.2 and submit the joint patch at some later stage when
I've got everything working?

No-one _else_ is working on this, are they?

All the best,

Norman


[1] http://sources.redhat.com/ml/autoconf-patches/2000-07/msg00287.html
http://sources.redhat.com/ml/automake/2000-07/msg00043.html

-- 
---
Norman Grayhttp://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK [EMAIL PROTECTED]





EXTRA_DIST and external or outside directories

2004-01-16 Thread jling
Is there a way to include a directory which is external or outside of 
the $(top_srcdir) and which is not involved in the build process?

I tried putting the following in my Makefile.am:

EXTRA_DIST = $(top_srcdir)/../../perl $(top_srcdir)/../../java

But, when I do a 'make dist' it does not attempt to include either of 
these directories in my tarball.

Is this because it ignores anything outside of the toplevel source 
directory?  Is there a work around?


Thanks,
John Ling