hard-link locking & filesystems
When a compiler is insufficiently cool, libtool uses hard-link locking to prevent the same file from being compiled in the same place. It does this by waiting until: ln /usr/bin/libtool whatever.lock succeeds. However, if libtool is installed on a different filesystem from where the compile is proceeding (/usr vs /home, for example), this will never succeed, and will sit there saying: Waiting for bcfmail.o.lock to be removed Waiting for bcfmail.o.lock to be removed Waiting for bcfmail.o.lock to be removed ... The hard-link-locking check in configure, naturally, does not catch this problem. Hard-link-locking, if we're to keep using it, should lock to a temp file created in the same directory. -jeff ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Building projects on i386-pc-solaris2.8
Hey, I rewrote a project's build process to use autotools and libtool. Everything builds fine but the binary seg faults at run time(in i386 solaris2.8 ). Does anyone know of any issues or AC_ AM_ macros that are absolutely required to build shared objects and dynamicly linked binaries(when porting to intel solaris2.8)? The binary builds and runs fine on Redhat 7.2. However when I build the target in i386-pc-solaris2.8 it segment faults when I run it. If I build it with out libtool and autotools it is fine. My make set up builds a few binarys that link to existing libs as well as some of the shared objects and libraries built with in the project. Not sure if the info I have included is helpful or not. Thanks in advance. i386-pc-solaris2.8 gcc version 2.95.3 20010315 (release) libtool 1.4.2 Al ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Building projects on i386-pc-solaris2.8
On Thu, Jan 31, 2002 at 02:04:27PM -0500, Allan McIntosh wrote: > I rewrote a project's build process to use autotools and libtool. > Everything builds fine but the binary seg faults at run time(in i386 > solaris2.8 ). Does anyone know of any issues or AC_ AM_ macros that are > absolutely required to build shared objects and dynamicly linked > binaries(when porting to intel solaris2.8)? > > The binary builds and runs fine on Redhat 7.2. However when I build the > target in i386-pc-solaris2.8 it segment faults when I run it. If I build > it with out libtool and autotools it is fine. Even if you --disable-shared? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
-lc fix for BSD/OS and FreeBSD
I was trying to run a CGI program with Apache 2.0.18 on BSDI BSD/OS 4.3, and found that when read() on a nonblocking pipe returned -1, errno wasn't setting set (to EAGAIN); it was 0. So apache didn't do its timeout call and the CGI request got a Server Error. The problem turned out to be that when linking libapr.so, libtool was adding -lc. Then, when libapr.so was linked into httpd, -lc gets linked in again, and there are now two copies of libc in apache's address space, each with its own thread-safe copy of errno. The version of libtool that came with Apache is: ltmain.sh (GNU libtool) 1.3.4-freebsd-ports (1.385.2.196 1999/12/07 21:47:57) However, the problem still exists in: ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18) The latter contains this case: *-*-netbsd*) # Don't link with libc until the a.out ld.so is fixed. ;; That case needs to be extended to: *-*-netbsd* | *-*-freebsd* | *-*-bsdi4*) # Don't link with libc until the a.out ld.so is fixed. ;; The FreeBSD port of libtool adds freebsd, and as I just discovered, BSD/OS needs the same treatment. This problem also recently bit Steven Schultz <[EMAIL PROTECTED]> while porting some video software from Linux to BSD/OS. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: -lc fix for BSD/OS and FreeBSD
I've found other problems on Solaris and Linux with libtool explicitly adding libc to the link line. One of the more recent hassles is with gcc 3.x; if you build a shared library with gcc and explicitly link -lc, gcc also links libgcc.so into your object. This gets to be a real hassle because now you have shared libraries that wrongly have a dependency on libgcc. Only linked executables are supposed to pull in libgcc, and it's really only critical for C++, not for plain C. It would be safest if libtool never added -lc to the link line, since all C compiler drivers already do it implicitly. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Dave MacKenzie > Sent: Thursday, January 31, 2002 7:23 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: -lc fix for BSD/OS and FreeBSD > > > I was trying to run a CGI program with Apache 2.0.18 on BSDI BSD/OS 4.3, > and found that when read() on a nonblocking pipe returned -1, errno wasn't > setting set (to EAGAIN); it was 0. So apache didn't do its timeout call > and the CGI request got a Server Error. > > The problem turned out to be that when linking libapr.so, libtool was adding > -lc. Then, when libapr.so was linked into httpd, -lc gets linked in again, > and there are now two copies of libc in apache's address space, each with its > own thread-safe copy of errno. > > The version of libtool that came with Apache is: > > ltmain.sh (GNU libtool) 1.3.4-freebsd-ports (1.385.2.196 1999/12/07 21:47:57) > > However, the problem still exists in: > > ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18) > > The latter contains this case: > > *-*-netbsd*) > # Don't link with libc until the a.out ld.so is fixed. > ;; > > That case needs to be extended to: > > *-*-netbsd* | *-*-freebsd* | *-*-bsdi4*) > # Don't link with libc until the a.out ld.so is fixed. > ;; > > The FreeBSD port of libtool adds freebsd, and as I just discovered, > BSD/OS needs the same treatment. > > This problem also recently bit Steven Schultz <[EMAIL PROTECTED]> while > porting some video software from Linux to BSD/OS. > > ___ > Libtool mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/libtool > ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Building projects on i386-pc-solaris2.8
> >On Thu, Jan 31, 2002 at 02:04:27PM -0500, Allan McIntosh wrote: >> I rewrote a project's build process to use autotools and libtool. >> Everything builds fine but the binary seg faults at run time(in i386 >> solaris2.8 ). Does anyone know of any issues or AC_ AM_ macros that are >> absolutely required to build shared objects and dynamicly linked >> binaries(when porting to intel solaris2.8)? >> >> The binary builds and runs fine on Redhat 7.2. However when I build the >> target in i386-pc-solaris2.8 it segment faults when I run it. If I build >> it with out libtool and autotools it is fine. > >Even if you --disable-shared? Then I get ld errors: Undefined first referenced symbol in file url_open /usr/local/lib/libltapi12.a(sgmlfiles.o) Fprintf /usr/local/lib/libltapi12.a(sgmllib.o) strcasecmp8 /usr/local/lib/libltapi12.a(sgmlparse.o) url_merge /usr/local/lib/libltapi12.a(dtd.o) Toupper /usr/local/lib/libltapi12.a(query.o) LTSTD_set_error_handler /usr/local/lib/libltapi12.a(sgmllib.o) LTSTDError /usr/local/lib/libltapi12.a(sgmllib.o) CharacterEncodingName /usr/local/lib/libltapi12.a(sgmlfiles.o) -- Allan McIntosh, Software Designer http://www.atreus-systems.com Phone: (613) 233-1741, (800) 764-5514 Ext 217 -- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
