Problems in cvs-version of libtool.
Hi, Trying to solve my problem with compiling C++ on Solaris, I downloaded and installed a newer of libtool version: /usr/bin/libtool --version ltmain.sh (GNU libtool) 1.4e (1.1178 2003/01/15 02:55:33) When compiling with: ./configure --with-omni=$HOME/omniorb --without-zlib --disable-static and (from the generated libtool, these two being hardcoded in my configure.in) # The linker used to build libraries. LD="/opt/SUNWspro/bin/CC -pta -G" # The archiver. AR="/opt/SUNWspro/bin/CC -xar" AR_FLAGS="-o" The linker fails with tons of messages like these: /bin/bash ../../../libtool --mode=link /opt/SUNWspro/bin/CC -mt -mt -o libtango.la -rpath /usr/local/lib -version-info 3:3:1 version.lo tangoSK.lo tangoDynSK.lo device.lo device_2.lo command.lo dserversignal.lo thsig.lo basiccommand.lo utils.lo dserverclass.lo dserver.lo class_factory.lo blackbox.lo classattribute.lo multiattribute.lo attribute.lo attrdesc.lo except.lo attrmanip.lo seqvec.lo pollring.lo pollobj.lo pollcmds.lo dserverpoll.lo pollthread.lo ../client/libclient.la -lpthread -lposix4 -L/home/users/e/es/esql/omniorb/lib -lomniORB4 -lomniDynamic4 -lpthread -lposix4 -lomnithread -lnsl -lsocket -L/home/users/e/es/esql/omniorb/lib -lpthread -lposix4 -lomnithread -lpthread -lposix4 /opt/SUNWspro/bin/CC -G -nolib -hlibtango.so.2 -o .libs/libtango.so.2.1.3 .libs/version.o .libs/tangoSK.o .libs/tangoDynSK.o .libs/device.o .libs/device_2.o .libs/command.o .libs/dserversignal.o .libs/thsig.o .libs/basiccommand.o .libs/utils.o .libs/dserverclass.o .libs/dserver.o .libs/class_factory.o .libs/blackbox.o .libs/classattribute.o .libs/multiattribute.o .libs/attribute.o .libs/attrdesc.o .libs/except.o .libs/attrmanip.o .libs/seqvec.o .libs/pollring.o .libs/pollobj.o .libs/pollcmds.o .libs/dserverpoll.o .libs/pollthread.o -Qoption ld -z -Qoption ld allextract ../client/.libs/libclient.a -Qoption ld -z -Qoption ld defaultextract -L/home/users/e/es/esql/omniorb/lib -lomniORB4 -lomniDynamic4 -lnsl -lsocket -lomnithread -lpthread -lposix4 -lc ld: fatal: symbol `bool Tango::operator==(const Tango::BlackBoxElt&,const Tango::BlackBoxElt&)' is multiply-defined: (file .libs/tangoSK.o and file .libs/tangoDynSK.o); ld: fatal: symbol `bool Tango::operator<(const Tango::BlackBoxElt&,const Tango::BlackBoxElt&)' is multiply-defined: (file .libs/tangoSK.o and file .libs/tangoDynSK.o); Anyone familiar with this? Erik. -- Actually it was supposed to be a work in progress, but then work got in the way of progress, so there's been no progress and it doesn't work ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Problems in cvs-version of libtool.
On Mon, Jan 20, 2003 at 03:27:25PM +0100, Erik Assum wrote: > ld: fatal: symbol `bool Tango::operator==(const Tango::BlackBoxElt&,const >Tango::BlackBoxElt&)' is multiply-defined: > (file .libs/tangoSK.o and file .libs/tangoDynSK.o); > ld: fatal: symbol `bool Tango::operator<(const Tango::BlackBoxElt&,const >Tango::BlackBoxElt&)' is multiply-defined: > (file .libs/tangoSK.o and file .libs/tangoDynSK.o); > > Anyone familiar with this? This isn't a libtool problem. Tell the omniorb people. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Problems in cvs-version of libtool.
* Albert Chin | On Mon, Jan 20, 2003 at 03:27:25PM +0100, Erik Assum wrote: | > ld: fatal: symbol `bool Tango::operator==(const Tango::BlackBoxElt&,const |Tango::BlackBoxElt&)' is multiply-defined: | > (file .libs/tangoSK.o and file .libs/tangoDynSK.o); | > ld: fatal: symbol `bool Tango::operator<(const Tango::BlackBoxElt&,const |Tango::BlackBoxElt&)' is multiply-defined: | > (file .libs/tangoSK.o and file .libs/tangoDynSK.o); | > | > Anyone familiar with this? | | This isn't a libtool problem. Tell the omniorb people. How is this, since it worked with an earlier version of libtool? Erik. -- ...as we saw Sweden: as the goldmine of sexual oppurtunity. -- Hanif Kureishi ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Problems in cvs-version of libtool.
On Mon, Jan 20, 2003 at 05:39:50PM +0100, Erik Assum wrote: > * Albert Chin > | On Mon, Jan 20, 2003 at 03:27:25PM +0100, Erik Assum wrote: > | > ld: fatal: symbol `bool Tango::operator==(const Tango::BlackBoxElt&,const >Tango::BlackBoxElt&)' is multiply-defined: > | > (file .libs/tangoSK.o and file .libs/tangoDynSK.o); > | > ld: fatal: symbol `bool Tango::operator<(const Tango::BlackBoxElt&,const >Tango::BlackBoxElt&)' is multiply-defined: > | > (file .libs/tangoSK.o and file .libs/tangoDynSK.o); > | > > | > Anyone familiar with this? > | > | This isn't a libtool problem. Tell the omniorb people. > > How is this, since it worked with an earlier version of libtool? So the *only* difference is the version of libtool? If so, do you have both? If you do, then recompile and mail a diff of the last libtool compile command (and the lines that follow it). -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: Solving the "relink exe's" libtool problem[take 3]
This patch passes my test. What do we need to do to get this accepted
into libtool cvs HEAD?
Earnie.
Charles Wilson wrote:
Okay, this version
1) puts lt-foo.c into .libs
2) "libtool --mode=clean" does the right thing --- cleans up foo,
foo.exe, .libs/foo.exe, .libs/lt-foo.c, plus whatever else it already
took care of.
3) lt-foo.c actually passes its own arguments to the shell wrapper -- it
didn't, before. (Oops)
libtool regression tests: no new failures (on cygwin)
briefly tested on another project; worked fine.
Binary packages for cygwin (libtool-devel-20030103-4,
libltdl3-20030103-4) available by pointing setup.exe at
http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/
--Chuck
Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/ltmain.in,v
retrieving revision 1.318
diff -u -r1.318 ltmain.in
--- ltmain.in 1 Jan 2003 01:57:47 - 1.318
+++ ltmain.in 13 Jan 2003 04:48:39 -
@@ -4284,6 +4284,207 @@
outputname=`echo $outputname|${SED} 's,.exe$,,'` ;;
*) exeext= ;;
esac
+ case $host in
+ *cygwin* | *mingw* )
+ cwrappersource=`echo ${objdir}/lt-${output}.c`
+ cwrapper=`echo ${output}.exe`
+ $rm $cwrappersource $cwrapper
+ trap "$rm $cwrappersource $cwrapper; exit 1" 1 2 15
+
+ cat > $cwrappersource <
+
+/* $cwrappersource - temporary wrapper executable for $objdir/$outputname
+ Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP
+
+ The $output program cannot be directly executed until all the libtool
+ libraries that it depends on are installed.
+
+ This wrapper executable should never be moved out of the build directory.
+ If it is, it will not operate correctly.
+
+ Currently, it simply execs the wrapper *script* "/bin/sh $output",
+ but could eventually absorb all of the scripts functionality and
+ exec $objdir/$outputname directly.
+*/
+EOF
+ cat >> $cwrappersource<<"EOF"
+#include
+#include
+#include
+#include
+#include
+#include
+
+#if defined(PATH_MAX)
+# define LT_PATHMAX PATH_MAX
+#elif defined(MAXPATHLEN)
+# define LT_PATHMAX MAXPATHLEN
+#else
+# define LT_PATHMAX 1024
+#endif
+
+#ifndef DIR_SEPARATOR
+#define DIR_SEPARATOR '/'
+#endif
+
+#if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \
+ defined (__OS2__)
+#define HAVE_DOS_BASED_FILE_SYSTEM
+#ifndef DIR_SEPARATOR_2
+#define DIR_SEPARATOR_2 '\\'
+#endif
+#endif
+
+#ifndef DIR_SEPARATOR_2
+# define IS_DIR_SEPARATOR(ch) ((ch) == DIR_SEPARATOR)
+#else /* DIR_SEPARATOR_2 */
+# define IS_DIR_SEPARATOR(ch) \
+(((ch) == DIR_SEPARATOR) || ((ch) == DIR_SEPARATOR_2))
+#endif /* DIR_SEPARATOR_2 */
+
+#define XMALLOC(type, num) ((type *) xmalloc ((num) * sizeof(type)))
+#define XFREE(stale) do { \
+ if (stale) { free ((void *) stale); stale = 0; } \
+} while (0)
+
+const char *program_name = NULL;
+
+void * xmalloc (size_t num);
+char * xstrdup (const char *string);
+char * basename (const char *name);
+char * fnqualify(const char *path);
+char * strendzap(char *str, const char *pat);
+void lt_fatal (const char *message, ...);
+
+int
+main (int argc, char *argv[])
+{
+ char **newargz;
+ int i;
+
+ program_name = (char *) xstrdup ((char *) basename (argv[0]));
+ newargz = XMALLOC(char *, argc+2);
+ newargz[0] = xstrdup("/bin/sh");
+ newargz[1] = fnqualify(argv[0]);
+ /* we know the script has the same name, without the .exe */
+ /* so make sure newargz[1] doesn't end in .exe */
+ strendzap(newargz[1],".exe");
+ for (i = 1; i < argc; i++)
+newargz[i+1] = xstrdup(argv[i]);
+ newargz[argc+1] = NULL;
+ execv("/bin/sh",newargz);
+}
+
+void *
+xmalloc (size_t num)
+{
+ void * p = (void *) malloc (num);
+ if (!p)
+lt_fatal ("Memory exhausted");
+
+ return p;
+}
+
+char *
+xstrdup (const char *string)
+{
+ return string ? strcpy ((char *) xmalloc (strlen (string) + 1), string) : NULL
+;
+}
+
+char *
+basename (const char *name)
+{
+ const char *base;
+
+#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
+ /* Skip over the disk name in MSDOS pathnames. */
+ if (isalpha (name[0]) && name[1] == ':')
+name += 2;
+#endif
+
+ for (base = name; *name; name++)
+if (IS_DIR_SEPARATOR (*name))
+ base = name + 1;
+ return (char *) base;
+}
+
+char *
+fnqualify(const char *path)
+{
+ size_t size;
+ char *p;
+ char tmp[LT_PATHMAX + 1];
+
+ assert(path != NULL);
+
+ /* Is it qualified already? */
+#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
+ if (isalpha (path[0]) && path[1] == ':')
+return xstrdup (path);
+#endif
+ if (IS_DIR_SEPARATOR (path[0]))
+return xstrdup (path);
+
+ /* prepend the current directory */
+ /* doesn't handle '~' */
+ if (getcwd (tmp, LT_PATHMAX) == NULL)
+lt_fatal ("getcwd failed");
+ size = strlen(tmp) + 1 + strlen(path) + 1; /* +2 for '/' and '\0' */
+ p = XMALLOC(char, size);
+ sprintf(p, "%s%c%s", tmp, DIR_SEPARATOR, path);
+ r
Re: [Mingw-users] Re: Solving the "relink exe's" libtool problem[take3]
Earnie Boyd wrote:
>
> This patch passes my test. What do we need to do to get this accepted
> into libtool cvs HEAD?
> > + newargz[0] = xstrdup("/bin/sh");
This may not be the shell and there is no point allocating it.
It is fine to use it from static memory.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: Solving the "relink exe's" libtool problem[take3]
Bruce Korb wrote:
Earnie Boyd wrote:
This patch passes my test. What do we need to do to get this accepted
into libtool cvs HEAD?
+ newargz[0] = xstrdup("/bin/sh");
This may not be the shell and there is no point allocating it.
It is fine to use it from static memory.
Okay, the second comment (use static string, not allocated memory) is
easy enough. But what's the best way to use "the shell"? Do a unquoted
replacement (<
...
newargz = XMALLOC(char *, argc+2);
EOF
$echo >> $cwrappersource <
newargz[0] = \"$SHELL\";
EOF
$echo >> $cwrappersource <<"EOF"
newargz[1] = fnqualify(argv[0]);
...
?
--Chuck
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) -DPIC
Robert Boehne <[EMAIL PROTECTED]> writes: > > All good ideas, and I don't really have a preference for any of them. > If you do, let me know or I'll just pick the one that looks easiest. I'd think an autoconf macro would be ok, to be used for instance AC_LIBTOOL_PICDEF([-DPIC]) AC_PROG_LIBTOOL which I guess would just insert its argument into $pic_flag. I wonder if it should work on a per-tag basis. Though for the GMP asm files stuff we're only interested in C, so that would be enough to start with. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: Solving the "relink exe's" libtoolproblem[take3]
Charles Wilson wrote:
>
> Bruce Korb wrote:
> > Earnie Boyd wrote:
> >
> >>This patch passes my test. What do we need to do to get this accepted
> >>into libtool cvs HEAD?
> >
> >
> >>>+ newargz[0] = xstrdup("/bin/sh");
> >>
> >
> > This may not be the shell and there is no point allocating it.
> > It is fine to use it from static memory.
>
> Okay, the second comment (use static string, not allocated memory) is
I wouldn't have mentioned the static string by itself ;-)
> easy enough. But what's the best way to use "the shell"? Do a unquoted
> replacement (
Re: [PATCH] Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) -DPIC
On Tue, Jan 21, 2003 at 09:13:54AM +1000, Kevin Ryde wrote: > Robert Boehne <[EMAIL PROTECTED]> writes: > > > > All good ideas, and I don't really have a preference for any of them. > > If you do, let me know or I'll just pick the one that looks easiest. > > I'd think an autoconf macro would be ok, to be used for instance > > AC_LIBTOOL_PICDEF([-DPIC]) > AC_PROG_LIBTOOL > > which I guess would just insert its argument into $pic_flag. Is setting a custom -DPIC really necessary? How about we just leave the existing -DPIC for the C and C++ tags? I don't see anything to gain by choosing a new default or allowing it to be set. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
