>
> > Thanks for this additional note.
> >
> >>from a previous mail:
> >
> >>>So, it's important, Ralf, that your 'file' changes NEVER generate a
> >>>false positive (e.g. saying something is an import lib when it is not).
> >>> If your code generates a false negative (saying something is static
>
On Wed, Feb 19, 2003 at 08:54:20PM -0500, Charles Wilson wrote:
>>2. This could be fixed by using the new direct-linking-to-dll
>>functionality for libraries with many symbols rsp. big import
>>libraries, which I hope will be available soon.
>
>right. What's the holdup there? IIRC, there are tw
Ralf Habacker wrote:
Now, the relative *offset* of that symbol might move around. But the
symname is not likely to change.
Thanks for this additional note.
from a previous mail:
So, it's important, Ralf, that your 'file' changes NEVER generate a
false positive (e.g. saying something is a
Igor Pechtchanski wrote:
I'm not libtool-savvy, so this may seem like a stupid question -- if it
is, let me know. However, I've been kinda following this discussion, and
haven't seen it answered. So here goes:
- How hard is it to add the capability to pass linker arguments through
the LD vari
> > You may be right in this issue, but couldn't the symbol "_dll_iname" doesn't
> > change in future implementation too ? The important question seems
> to me like
> > this: [1] Which is the mostly stable identifier we build on ?
>
> filenames change because evil twisted pesky end-users change the
On Sun, 16 Feb 2003, Charles Wilson wrote:
> Max Bowsher wrote:
>
> >>>But, that's neither here nor there. IF these crossbreed implibs are
> >^^
> > libuuid.a at least is static *only* - not crossbreed. So there really is no
> > way
Max Bowsher wrote:
Besides, this means altering the platform to suit libtool. Talk about the
tail wagging the dog!
see below
The only alternatives for this particular problem seem to be:
1) punt.
Well, it's not like we've got many complaints about this.
2) delay. --enable-runtime-pseu
Max Bowsher wrote:
But, that's neither here nor there. IF these crossbreed implibs are
^^
libuuid.a at least is static *only* - not crossbreed. So there really is no
way for libtool know to allow it except by name.
Ugh. You'r
Ralf Habacker wrote:
the negative: Ralf, you keep trying to assume things based on filenames.
Filenames LIE. Whether it is the name of the archive (foo.dll.a) or
the name of an object in the archive (dxx.o), it's gonna fail -- and
it will fail in EXTREMELY hard-to-track-down ways.
You ma
> > Thats very bad.
> >
>
> Yeah. I don't know why these implibs need to declare these static
> structures; it's possible that w32api is just following the lead of the
> corresponding .lib files in the MSVC distribution.
>
> But, that's neither here nor there. IF these crossbreed implibs are
> de
Charles Wilson wrote:
> Max Bowsher wrote:
But, that's neither here nor there. IF these crossbreed implibs
>> ^^
>> libuuid.a at least is static *only* - not crossbreed. So there
>> really is no way for libtool know to allow it e
Charles Wilson wrote:
> Charles Wilson wrote:
>
>>> I think that in some cases, libtool tries to do too much. I've run
>>> into a number of cases which would have just worked if libtool had
>>> passed the arguments to gcc without modification, but it insists on
>>> filtering
>>> stuff in
>>> comple
Charles Wilson wrote:
I think that in some cases, libtool tries to do too much. I've run into a
number of cases which would have just worked if libtool had passed the
arguments to gcc without modification, but it insists on filtering
stuff in
complex ways. For example, gcc -print-search-dirs doe
Max Bowsher wrote:
Neither will work. The compiler is already perfectly happy. libtool decides
it knows better, though, and intervenes, breaking the build. I wouldn't
worry too much about this now. There's already a hardcoded
sys_lib_search_path_spec for cygwin. It only affects building for ming
Charles Wilson wrote:
>> Ralf Habacker wrote:
> BTW: Do you know which libraries are also hybrid execpt of
> cygwin1.dll ?
>>>
>>>
There are about a half-dozen in /usr/lib/w32api -- and worse, the
static
>>>
>>> members are "bad" variable types; if you make the static members
>>>
On Mon, 17 Feb 2003, Charles Wilson wrote:
> Max Bowsher wrote:
>
> > Besides, this means altering the platform to suit libtool. Talk about the
> > tail wagging the dog!
>
> see below
>
> >>The only alternatives for this particular problem seem to be:
> >>
> >>1) punt.
> >
> > Well, it's not like
On Mon, 17 Feb 2003, Charles Wilson wrote:
> Max Bowsher wrote:
>
> >
> > Neither will work. The compiler is already perfectly happy. libtool decides
> > it knows better, though, and intervenes, breaking the build. I wouldn't
> > worry too much about this now. There's already a hardcoded
> > sys_l
Ralf Habacker wrote:
BTW: Do you know which libraries are also hybrid execpt of cygwin1.dll ?
There are about a half-dozen in /usr/lib/w32api -- and worse, the static
members are "bad" variable types; if you make the static members part of the
DLL, then these vars can't be auto-imported wit
>convenience libs do not count. You can still link a DLL with convenience libs,
because it is assumed that a true convenience lib is built by your project, for
your project, and only for your project -- it is not available to "outside
users" and therefore there can never be any mismatch between th
>>BTW: Do you know which libraries are also hybrid execpt of cygwin1.dll ?
>There are about a half-dozen in /usr/lib/w32api -- and worse, the static
members are "bad" variable types; if you make the static members part of the
DLL, then these vars can't be auto-imported without using pseudo-reloc
Ralf Habacker wrote:
This depends on how the hybrid lib is created. If it starts with the static
object files, it would be identified as static, if it starts with the import
library as import library.
right.
BTW: Do you know which libraries are also hybrid execpt of cygwin1.dll ?
There are
> But, you'd still need to check all "static libs" to see if they are
> really import libs after all. The good news it that we expect this to
> happen only rarely: when an import lib is a "hybrid" lib with static
> objs "in front" --> the modified 'file' test incorrectly identifies it
> as a stat
Max Bowsher wrote:
ARGH. This defeats the whole purpose of the policy change -- and it
is a policy change driven by the libtool development
I've been hunting for the relevant threads on the libtool list - can't find
them. Can anyone offer URLs or search terms that would help?
I think it was
Ralf Habacker wrote:
ARGH. This defeats the whole purpose of the policy change -- and it is
a policy change driven by the libtool development. I don't want to
support a forked version of libtool that differs from mainline on a
basic policy issue.
May be, but like Max has stated, I don't like
Christopher Faylor wrote:
> gcc doesn't search /usr/lib/w32api. ld does. Since it's impossible
> for ld to *not* search /usr/lib/w32api, I don't know why this is an issue
> unless you've got a mismatch between gcc and ld.
It's an issue when cross-compiling cygwin -> mingw, using -mno-cygwin, sin
On Mon, Feb 10, 2003 at 08:02:17PM -, Max Bowsher wrote:
>>> ARGH. This defeats the whole purpose of the policy change -- and it
>>> is a policy change driven by the libtool development.
>
>I've been hunting for the relevant threads on the libtool list - can't find
>them. Can anyone offer URLs
>> ARGH. This defeats the whole purpose of the policy change -- and it
>> is a policy change driven by the libtool development.
I've been hunting for the relevant threads on the libtool list - can't find
them. Can anyone offer URLs or search terms that would help?
Ralf Habacker wrote:
> May be,
> ARGH. This defeats the whole purpose of the policy change -- and it is
> a policy change driven by the libtool development. I don't want to
> support a forked version of libtool that differs from mainline on a
> basic policy issue.
>
May be, but like Max has stated, I don't like to be forced t
Ralf Habacker wrote:
1) x86 DLL (and EXE)
2) x86 archive static
3) x86 archive import
4) other
Do NOT try to combine 2) and 3) -- which is what all of your suggestions
in this email would do.
[1]
What about extending the 'file' tool, which supports already 1, (2 combined with
3) and 4 ?
You h
> Ain't gonna happen. Find me a faster way to distinguish between x86
> import libs and x86 static libs (and random-other-architecture libs of
> any sort), and I'll thank you.
>
see [1]
> But telling me that I must support a fundamental philosophical and not
> merely technical fork of libtool fo
Charles Wilson wrote:
> Max Bowsher wrote:
>> This seems like a good time to mention that I ran into this problem
>> building gtk+ (or glib), I forget. It wanted -luuid, but -luuid is a
>> static archive, which libtool doesn't currently like. I had to hack
>> libtool as Ralf mentions above to get i
Ralf Habacker wrote:
Ralf -- please drop my 'final' script into one of your generated
libtools and run your tests (what? rebuilding KDE?) on it, and let me
know what you think. (Oh, and since (a) 'file' execution speed is
invariant with target size, and (b) we match *DLL* and *executable*
separat
Ralf Habacker wrote:
1.4e isn't a specific version. It just means "some cvs checkout after the
1.4d release"
but this could be a long period: :-)
The recent devel libtool tells:
$ libtool --version
ltmain.sh (GNU libtool) 1.4e (1.1175 2003/01/01 01:57:46)
ltmain of recent kde from anoncvs.kde
Max Bowsher wrote:
1.4e isn't a specific version. It just means "some cvs checkout after the
1.4d release"
Right. But when? And on which branch? 1.4-branch CVS, or HEAD CVS
(which is to say, pre-1.5)? Granted, libtool's CVS organization and
branch naming could be better, but AFAIK KDE stil
> 1.4e isn't a specific version. It just means "some cvs checkout after the
> 1.4d release"
but this could be a long period: :-)
The recent devel libtool tells:
$ libtool --version
ltmain.sh (GNU libtool) 1.4e (1.1175 2003/01/01 01:57:46)
ltmain of recent kde from anoncvs.kde.org:
VERSION=1.4e
Ralf Habacker wrote:
> Chuck, this script does not work with original libtool 1.4e
1.4e isn't a specific version. It just means "some cvs checkout after the
1.4d release"
> file_magic (win32_libid): 50 sec from make start until the ar(!)
> command line comes up. The problem I've got with this is
> From 'info libtool':
>
>`pass_all'
> will pass everything without any checking. This may work on
> platforms in which code is position-independent by default and
> inter-library dependencies are properly supported by the dynamic
> linker, for example, on DEC OSF/1 3
> Ralf -- please drop my 'final' script into one of your generated
> libtools and run your tests (what? rebuilding KDE?) on it, and let me
> know what you think. (Oh, and since (a) 'file' execution speed is
> invariant with target size, and (b) we match *DLL* and *executable*
> separately, if you
From 'info libtool':
`pass_all'
will pass everything without any checking. This may work on
platforms in which code is position-independent by default and
inter-library dependencies are properly supported by the dynamic
linker, for example, on DEC OSF/1 3 and 4.
From ltmain
Hi Charles,
I've taken a deeper look into the libtool sources and found a hint relating to
the way other os do this checking, for example
libtool.m4.in
# AC_DEPLIBS_CHECK_METHOD
pass_all
gnu*)
irix5* | irix6* | nonstopux*)
linux*) (most hosts)
osf3* | osf4* | osf5*)
sco3.2v5*)
solari
Okay, using a more 'fair' metric on speed (don't throw a lot of
'unknowns' at the libid() function; libtool presumably will only present
things that IT believes are libraries or DLLs for identification.
Unless the user mis-specifies something. So, using THIS test routine,
which only grabs .dll
> You never followed up on that.
Rebooting every time need very much time (about 10 minutes for me) and there is
an easier way to emulate that. I've written an applications which's allocate any
available memory. This removes all cached files' dll's and so one. I had similar
problems while inspecti
Ralf, this is the last message in the thread you mentioned.
Charles Wilson said:
> You've shown that win32_libid() as it is currently can take up to 5
> seconds on a single "library", while most "libraries" can be
> identified in 0.3-0.6 seconds. But that doesn't address how much
> longer win32_l
Christopher Faylor wrote:
How hard could this all be??
Maybe I'll work on this in my "copious spare time". Chuckle. Snort.
That's a good one.
Oh, and the GPL sucks. Have I mentioned that? Have I? Huh? Should
I mention it again in case you missed it?
I can't decide whether to la
On Wed, Feb 05, 2003 at 10:07:45PM -0500, Charles Wilson wrote:
>It's not that you didn't chime in with your speedup patches. Its that
>you apparently didn't bother to read the emails in the discussion, so
>that when you DID chime in, it was with (slightly) offtopic and
>(mostly) unhelpful at this
Ralf Habacker wrote:
Chuck, about two month ago we had a private discussion about the file_magic
stuff, where i have investigated about 7 hours to figure out a faster approach
for identifing import library file types, because the implementation you have
mentioned would increase the kde compiling t
> Yes, Ralf, I know. This is like the sixth iteration trying to solve
> this problem. The very first attempt did what you suggest (only it is
> much much more complicated than you imply; you're overlooking a lot).
> However, that fix was unacceptable to the automake and libtool people.
> Hence,
Christopher Faylor wrote:
I don't suppose that the idea was squashed because symlinks don't work
for mingw. Although I guess they do work courtesy of cygw, er, msys.
Yeah, all of the autotools on mingw depend on MSYS==cygwin for basic
functionality. So they get symlink support "for free".
-
On Mon, Feb 03, 2003 at 10:04:33PM -0500, Charles Wilson wrote:
>But, in any case, *even if it worked in all cases*, it's too late. At
>this point, this IS the mechanism that libtool will use; it's been
>through the wringer with the folks on the automake list, libtool list,
>and has been tested
Ralf Habacker wrote:
i've played a little with this stuff and have seen, that at least for cygwin
there is an easier way to deal with this. Create a simple link from 'foo' to
'foo.exe' and Makes need are fullfilled.
See ltmain.sh:
# The program doesn't exist.
\$echo \"\$0: error: \$pr
[EMAIL PROTECTED] wrote:
There were several solutions:
1) Teach 'make' to only want 'foo' instead of 'foo.exe'. There are
problems here -- this requires mucking with automake, which has the
potential to break non-libtool builds if not done carefully.
Do you have seen thatg ltmain.sh defi
Hi Chuck,
>3) What I did: create a binary wrapper -- an actual executable --
> named 'foo.exe' in the main build directory. It is NOT the real
> foo.exe. It simply exec's the shell script, which in turn sets up the
> environment and exec's the real .lib/foo.exe. Eventually, the 'set up
> th
I've updated libtool-devel to the 20030121 CVS, plus added a major
change of my own (inspired by Earnie Boyd and others on the libtool
mailing list) that "fixes" the 'relink exe's over and over and over'
problem on both mingw and cygwin.
[Skip to the last two paragraphs for the real import
I've updated libtool-devel to the 20030121 CVS, plus added a major
change of my own (inspired by Earnie Boyd and others on the libtool
mailing list) that "fixes" the 'relink exe's over and over and over'
problem on both mingw and cygwin.
[Skip to the last two paragraphs for the real important p
54 matches
Mail list logo
