; tarball is that it's standalone and the user shouldn't need
any special developer tools to build it, other than a shell, compiler,
and make.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
) manually inspecting a
diff of the header files (3) looking at the accumulated NEWS/Changelog
entries for possible changes in semantics.
I am open to suggestions for reducing human error... thanks.
--
Brian Gough
GNU Scientific Library -
http://www.gnu.org/so
nalogous to the ELF DT_NEEDED tag. If you
specify a lib on the link command line but no symbols in it are
referenced from the program being linked, it's a no-op, so the problem
that this option was invented to solve doesn't exist there.
Brian
_
l happens to contain
PIC objects, so it assumes it doesn't which is correct in the vast
majority of cases.
Now AFAIK libtool will create archives of PIC objects for convenience
libraries. But these are never installed and always under the control
of libtool so it
engines have an uncanny habit of finding those old
copies and putting them near the top of the results, which leads to a
lot of confusion if the neglected version evades deletion long enough
such that it documents a long-obsolete version.
Brian
Bruce Korb wrote:
Hi Brian, Harlan, and libtool-ers,
On Tue, Jun 24, 2008 at 4:59 PM, Brian Utterback
<[EMAIL PROTECTED]> wrote:
Bruce is correct that the problem has to do with "-R" but you don't do
"-R" the way he is using it here.
I need to
ut they would be
essentially empty files. I know, not the cleanest solution.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
e,
you may want to fortify this in various ways: pick a more appropriately
named temp dir, make sure it's empty at first, sanity check the list of
files to delete, ensure the package supports DESTDIR (vs. prefix
overriding) etc. But you get the general idea of the method. Some
packages gener
import libs, so
I'd consider this a bug in the ICU package if it can't generate one.
One can be created as a side effect of linking the DLL simply by adding
-Wl,-out-implib,libfoo.dll.a.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
milar set for the C++ runtime and the mixed managed/native
runtimes as well, see
<http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx>. ]
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
com/cgi-bin/man-cgi?ld++NetBSD-current>
Irix ld:
<http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/u_man/cat1/ld.z>
Looks like Tru64 does not however:
<http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51_HTML/MAN/MAN1/01
n't you just try a test link with -Bstatic -lfoo, if that succeeds
then use that, otherwise fall back to just -lfoo.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
ut since
it's a native MinGW app that only speaks Win32 paths. I'd recommend
using MinGW+MSYS instead if you don't intend to build Cygwin programs.
Also relocatability is a whole other ball of wax that you have to
address when building for MinGW, because the user expectation is that
ng just named differently. Don't confuse the
libfoo.a name with a static library which has the same style name but is
a totally different thing (and that's why it's considered deprecated to
name an import library libfoo.a, but some are still done that way, e.g.
all of w32api.)
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
ould result in both a decorated and
undecorated alias of each symbol being exported, so you don't have to
try to pretend that gcc isn't emitting calls to decorated names when it
really is.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
be helpful
to know what object or library contains the symbols that are listed as
undefined.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
gets in the way.)
or
B. Ship with an install script that updates /etc/ld.so.conf to add
the required paths.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
ersion 27.1.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
On 10/9/07, Brian <[EMAIL PROTECTED]> wrote:
>
> Peter, `autoreconf -fi' fixed it. Thank you!
Peter, `autoreconf -fi' fixed it. Thank you!
On 10/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> On Mon, Oct 08, 2007 at 06:38:11PM -0600, Brian wrote:
> > Peter, thanks for your comments. I build libtool from source, and am
> using
> > 1.5.24. I man
'Gorman <[EMAIL PROTECTED]> wrote:
>
>
> On Oct 9, 2007, at 1:02 AM, Peter O'Gorman wrote:
>
> >
> > On Oct 7, 2007, at 5:07 AM, Brian wrote:
> >
> >> I am trying to make a universal binary out of our software on OSX.
> >> The general strateg
SIGOURE <[EMAIL PROTECTED]> wrote:
>
> On Oct 7, 2007, at 5:07 AM, Brian wrote:
>
> > I am trying to make a universal binary out of our software on OSX.
> > The general strategy is to configure with LDFLAGS/CXXFLAGS="-arch
> > i386 -arch ppc". This seems t
without resorting to building on the actual hardware for
each and lipo'ing them together?
Thanks and cheers,
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
#x27;re using Cygwin) and hence the
import library is the thing that selects which version of the library to
link against.
For example on Cygwin:
$ ls -l /usr/bin/cygintl* /usr/lib/libintl*
-rwxr-x---+ 1 brian Users 22K Dec 13 2001 /usr/bin/cygintl-1.dll
-rwxr-x---+ 1 brian Users 37K Aug 10 2003 /usr
p.lib version.o
> ../libtool: line 5973: lib: command not found
I'm not sure why it's trying to use lib here, that seems wrong if you're
using gcc/binutils. Possibly a configure problem?
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
out the -.
I don't see why you can't just use -avoid-version.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
y represent
locations, not data. You can refer to them in your C code only as
&__foo__, never as __foo__. I don't know why they are marked U. In any
case, this is not at all the same situation as function or data imports.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
bout the maintainer telling
libtool that it is safe to assume or not assume something. So yes, you
need to either use -no-undefined unconditionally, or conditionalized on
PE targets. See
<http://article.gmane.org/gmane.comp.gnu.mingw.user/18727> for a little
of the history.
Brian
ainers do not want
the burden of having to maintain an ABI given its history of not being
designed as such. So it seems like a really bad idea to jump through
hoops to make it shared, as you'd end up with the situation you
mentioned dozens of cygbfd-.dll files
wo different names for the
exact same thing. I don't know why you're bothering with a .def file,
either. You can simply do -Wl,--out-implib,foo.dll.a to have the import
library created at the same time as the .dll. You can rename/copy
e not necessary so once you
upgrade your binutils there will be a size penalty to not using
dllimport also.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
debatable, you don't want to do
that if you can avoid it, which you can by just using -DPCRE_STATIC,
which is how it was designed to work.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
eally. A .def file is used to
express what symbols a given .dll exports and imports, but these
concepts don't even exist in the case of a static library.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
Duft Markus wrote:
> Additionally cygwin does not
> correctly work on SMP machines with win2k or higher.
Need a shovel for that FUD you're slinging?
___
http://lists.gnu.org/mailman/listinfo/libtool
egated so that no modern libs pollute the build.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
-xlc... gcc -no-cygwin
>
> What is this i686-pc-mingw32-xlc business?
That would appear to be libtool or autoconf searching for a working C
compiler, since "gcc -no-cygwin" probably gave an error about incorrect
parameters. But that's just a wild guess.
Brian
__
shared library libshared-0.dll. The only
one of the four that fails to build is the static plugin version, which
dies with the duplicated symbol problem.
$ ls -l
total 1737
-rwxr-xr-x1 brianAdminist 588238 Jun 11 19:08 LTDLOpened-0.dll
-rw-r--r--1 brianAdminist 1194
when creating libShared and
libLTDLopened indicates this.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
:Buffer::readString(std::basic_string, std::allocator >&)':
buffer.cc:(.text+0x6c1): undefined reference to `std::basic_string, std::allocator >::assign(char const*,
unsigned int)'
In any case, this is not the right list to post on. I suggest yo
tails, such as how you configured
the package. When trying to build a mingw package under Cygwin you are
in effect cross compiling, so the configury should probably look
something like the following, although there are many ways to skin a
cat:
./configure --host=i686-p
e with "CC=gcc
-mno-cygwin", do it in its own build tree away from the Cygwin build
tree, just as if you were cross compiling.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
ere is no way to influence the DLL
search process since that is done by the Windows dynamic loader. ]
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
ackage's
author so that he/she can address the version disparity (if that indeed
is the problem.)
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
r in /usr/ccs/bin so that would work.
--
Brian Gough
___
http://lists.gnu.org/mailman/listinfo/libtool
t to
bail out if ar is not found?---since I'm building static and shared
libraries it is always going to be needed I think.
Thanks for any insights,
--
Brian Gough
(GSL Maintainer)
http://www.gnu.org/software/gsl/
___
http://lists.gnu.org/mailman/listinfo/libtool
R' option doesn't support relative path.
Can someone tell me why or if there is a workaround?
Thanks
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
m to like to add whole categories. Although a configure check
or some kind of fallback would be best.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
r way of handling this. I will
follow up on the appropriate Cygwin list.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
ory 'Utils' and not
'Devel' so even if you select all of 'Devel' you won't get it.
If libtool currently displays somewhat degraded or broken behavior
without 'file' then it would be a good idea to at least add 'file'
er/qt-mac-free-3.3.5/lib/libqt-mt.dylib -lz -ldl -lreadline
-lSM -lICE -lX11 -lXext -lXmu -lXt -lXi -lCoin -ljpeg -lSoQt -framework OpenGL
-- Cheers,Brian MingusAIM, Skype: BReflectionGoogle talk: [EMAIL PROTECTED]Phone: (720) 771-2599
___
http://lists.gnu.org/mailman/listinfo/libtool
Cheers,--Andy Wingo
http://wingolog.org/-- Forwarded message --From: Noah Misch <[EMAIL PROTECTED]ech.edu>Date: Sep 15, 2005 12:35 PM
Subject: Re: Configure is checking for fortran yet I have no fortran code or checksTo: Brian <[EMAIL PROTECTED]>Cc: autoconf@gnu.org
On Thu, Sep 15, 2
Brian Dessent wrote:
> It seems clear that Cygwin would benefit from some kind of special
> casing in the shell because of the fork penalty, but apparently
> no one has the time or is capable of providing this, if it's even feasible.
Uhh, nevermind. Upon checking it seems th
xec. It seems
clear that Cygwin would benefit from some kind of special casing in the
shell because of the fork penalty, but apparently no one has the time or
is capable of providing this, if it's even feasible.
[*] http://marc.theaimsgroup.com/?
are in the original libltdl
directory? I admit to not understanding all the details, but that was
enough to clear up the problem for me (as one would expect - the
installed sources of libltdl should be setup correctly...). Seems much
easier than any of the other options.
Brian
--
Brian Barrett
Title: She was a really nasty girl, in fact a sadist.
Laura made a strident sound.k2e4580n84750at53lpz58b6849vd043m6476g36e2963c886617823917i9
S.URPRISE YOUR L.OVER TODAY! COVER HER WHOLE FACE WITH C.UM!
How w.ould you like to
SHOOT LIKE THE PO.RN-STARS?
Up to 500% more S.PERM!
ADD UP_TO 500% MOR
something completly in the configuration
of libtool and/or automake?
Thanks to Bruce for pointing me in the right direction..
Cheers,
Brian
On 2002.04.10 18:43 Bruce Korb wrote:
> "Brian W. Taylor" wrote:
>
> > I found that if I make
$run $rm $removelist
exit $error
fi
fi
fi
I can kinda get it to work. But I get this failure mode also
mv: cannot rename lsidtm.o: No such file or directory
It seems as through the mv command is being executed more t
le this would work, it has the (IMHO) nasty side affect that any
libraries previously installed in, say /usr/lib, will take priority (I
think) over the library that was just built in the source code tree.
It also means hacking around with the Makefiles.
--
Brian May <[EMAIL PROTECTED]>
when creating Debian packages).
If an old copy of the library exists in /usr/lib, then that will get
used instead of the library that has just been compiled.
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
n testing.
I understand that libtool has a specific versioning convention and
we don't want you to change that. It's just that if the REVISION
part could accomodate a 6-digit number (with leading zeros) we'd
be grateful.
-Brian
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
arched /usr/lib first(??), it might link the wrong version of
the library.
My preferred fix would be to replace instances of
.../path/to/lib/liba.la
with something like
.../path/to/lib/.libs/liba.so
which would be guaranteed to get the correct library.
--
Brian May <[EMAIL PROTECTED]>
_
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> The problem has to do with requiring relinking at
Alexandre> install time. This is ne
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
Alexandre> In general, when relinking is necessary, you must not
Alexandre> use a different prefix to install than the one used to
Alexandre> build.
Brian> In which case, you are
o, why did this work with libtool 1.4, but then suddenly stop
working?
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
#x27;.
make[1]: Leaving directory `/home/bam/tmp/libtool-1.4/mdemo'
[note: this test conducted on a stable Debian system; it also fails on
unstable. It use to work on unstable, the only change I can think of
is Linux 2.4.4 instead of 2.4.3 and glibc 2.2.3 instead of 2.2.2 ]
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
nk convenience libraries need to compile two sets
of libraries: *.a which contains non-PIC code and *.al which contains
PIC code.
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
look at this, I will, after I am satisfied the
previous problems have been fixed (with regards to interlibrary
dependencies).
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
Brian> /usr/lib/libz.so -> libz.so.1.1.3 /usr/lib/libz.la ->
Brian> libz.la.1.1.3 /usr/lib/libz.so.1 -> libz.so.1.1.3
Brian> /usr/lib/libz.so.1.1.3 /usr/lib/libz.la.1.1.3
Me a
et matters straight (I am still not quite sure of
this). For situation
i) what linking libx.la, the version pointer to by libx.so is used?
ii) when dlopening libx.la, the version pointed to by libx.so is used?
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
Alexandre> Presumably, libz.la would be that from the older
Alexandre> version, since libz.la is used for linking. And then,
Alexandre> because libtool sets dlname to the SONAME of the
Alexandre> latest version thereof (as per the lib package). Or
Alexandre> something like that :-)
Agreed.
In the discussion on debian-policy, there was some concern that this
system would break ldconfig, but it appears that these concerns are
not justified. For instance ldc
his is already a potential
problem (programs designed for libz.so.1 could mistakenly use the
libz.la file from libz.so.2 build). So I won't consider these
problems here.
Any comments?
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
(eg. the
run time search path specifying the installation path - at least this
way it should work, I think?).
No sense in breaking a feature on *all* platforms just because some
can't cope...
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
that is the programmers fault, and libtool shouldn't go out of its way
to try and resolve/break the issue.
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
roject. Then it adds the
Wesley> right -L options.
That seems to help the 2nd problem, Thanks.
Any ideas on the first problem?
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
ared l2.lo -L/usr/lib -ll1 -Wl,-soname -Wl,libl2.so.0 -o
.libs/libl2.so.0.0.0
/usr/bin/ld: cannot find -ll1
collect2: ld returned 1 exit status
libtool: install: error: relink `libl2.la' with the above command before installing it
libtool: install: warning: remember to run `libtool --fini
>>>>> "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes:
>> On Tue, Jan 16, 2001 at 01:50:57PM +1100, Brian May wrote: >
>> Oh, another observation: installing the libraries in their
>> non-final > location (as required for Debia
ken from Heimdal).
(oh, before my patch the upstream version also had:
libvers_la_LDFLAGS = -static
which meant non-PIC code was compiled in the shared libraries. I didn't
like this, so removed it).
--
Brian May <[EMAIL PROTECTED]>
___
Li
depdemo.static
/home/bam/source/cvs/libtool/depdemo/a/bin/depdemo.static
/usr/bin/install -c depdemo.static
/home/bam/source/cvs/libtool/depdemo/a/bin/depdemo.static
make[2]: Nothing to be done for `install-data-am'.
make[2]: Leaving directory `/ho
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
Brian> Hello, according to the
Brian> http://www.gnu.org/software/libtool/>, the mailing
Brian> list archives for this mailing list are kept at
Brian> http://www.geocrawler.com/l
er.com/archives/3/404/2000/9/0/4316399/>
(although that prediction seems to be overly optimistic now :-(. )
So, is there anything wrong with the mailing list and/or archives, or
is there nothing worth getting discussed?
--
Brian May <[EMAIL PROTECTED]>
80 matches
Mail list logo
