Re: bogus warning 'seems to be moved'
On 22/09/2010 09:49, Marco Atzeri wrote: Dear developers, is this bogus warning avoidable in the next release ? libtool: link: warning: `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfontconfig.la' seems to be moved libtool: link: warning: `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libexpat.la' seems to be moved ... as the files are /usr/lib/libfontconfig.la /usr/lib/libexpat.la .. the *.la files did not moved at all I see this warning re: libintl when I build libgcj. In that case, it happens because for some reason (I haven't established yet whether this is down to libtool or the libgcj makefile) something goes wrong with directory search paths, and /lib appears in the list ahead of /usr/lib. As a consequence, libtool finds the .la file via Cygwin's /lib mountpoint rather than the real /usr/lib path, all the relative paths are wrong and it looks like the control script has been moved. This shows up in the warning it issues: libtool: link: warning: `/lib/libiconv.la' seems to be moved I wonder if your problem has a similar cause underlying in some way? cheers, DaveK ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool versioning
On 04/05/2010 18:56, Ralf Wildenhues wrote:
I'll apply the patch below soon unless I hear complaints.
Complain is too strong a word for what I'm about to do... nitpick, quibble
or kibbitz might be better :) Disclaimer aside, ...
-The following explanation may help to understand the above rules a bit
+The following explanation can help to understand the above rules a bit
Either might or may sound appropriate here, but can is a bit
odd-sounding to this native speaker's ears.
If we were re-wording the sentence to make the listener the explicit
subject, we would write You may find the following explanation helpful or
You might find the following explanation helpful but not You can find the
following explanation helpful; the first two describe something that is a
possible state of affairs, but in the can formulation it sounds like the
speaker is giving the listener permission to find the explanation helpful.
Saying that the explanation can help makes the explanation sound like an
active agent rather than a passive object: it is the reader who can or can not
help themselves, using the explanation to do so, rather than the explanation
that jumps up and sets about helping the reader.
-drop-in replacement, but programs using the new version may use APIs not
+drop-in replacement, but programs using the new version can use APIs not
I'd have left this one alone, the use of may emphasises that it is
conditional/subjunctive, which I think is the more important sense of the
sentence than the are able to sense which is implied.
present in the previous one. In other words, a program linking against
-the new version may fail with ``unresolved symbols'' if linking against
+the new version might fail with ``unresolved symbols'' if linking against
the old version at runtime: set @var{revision} to 0, bump @var{current}
and @var{age}.
@item
-Programs may need to be changed, recompiled, relinked in order to use
+Programs might need to be changed, recompiled, relinked in order to use
the new version. Bump @var{current}, set @var{revision} and @var{age}
These last two I'd say too close to call, purely a matter of personal taste.
cheers,
DaveK
Re: [PATCH 1/4] Support GCC LTO on GNU/Linux.
On 06/04/2010 22:39, Paolo Bonzini wrote: On 04/06/2010 04:01 AM, Charles Wilson wrote: As for whether it would get dropped if you did, I'd imagine that's quite plausible; you might want to add a volatile qualifier. 'static volatile const char * MAGIC = ...' ^^ err...maybe just 'volatile'! Volatile const _does_ make sense to the compiler, believe it or not. :-) Yep, that was no typo on my part, I meant exactly what I said :) cheers, DaveK
Re: [PATCH 1/4] Support GCC LTO on GNU/Linux.
On 04/04/2010 18:53, Charles Wilson wrote: One thing I worry about -- but can't test on my platform, since cygwin's compiler is not up to the latest-and-greatest yet so doesn't yet support LTO -- is whether this bit, in the cwrapper, will break: const char * MAGIC_EXE = $magic_exe; It's been my understanding that sticking random static variables into an application, when that variable is never accessed by the app's code, is one of the things that gets optimized out by LTO. Can anybody confirm that this sort of thing will continue to work, even with LTO turned on? There's surely no need to build the wrapper with LTO just because the target application is built that way? As for whether it would get dropped if you did, I'd imagine that's quite plausible; you might want to add a volatile qualifier. cheers, DaveK
Re: how to parse gcc -v output
On 04/04/2010 20:08, Joseph S. Myers wrote: I think extracting compiler/linker *internal commands* and trying to process or adapt them is inherently fragile and liable to break whenever new compiler/linker options (internal or otherwise) are added. If possible the aim should be to work out user-friendly interfaces for direct GCC users and have libtool use the same interfaces while expecting how they are implemented to change over time. Interfaces by which GCC does things (e.g. link a shared library for the multilib implied by the given options) seem safer than interfaces where it gives information (if you ask it for directories and lists of libraries, you might then find that interface inadequate for handling per-library choice of static or shared libraries, for example). Essentially, libtool needs to know about gcc's specs, and what they do to a command-line. ISTM that using -### and the appropriate language-dependent driver should do most things that libtool needs, but maybe we should add an option to the driver that turns it into a command-line driven arbitrary specs processor of some kind. Ralf, might that help the situation, if you could pass arbitrary command-lines to the driver and have it report back the results of spec processing in some controlled and parseable fashion? cheers, DaveK ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: How to build a noinst_ but still shared library?
On 22/03/2010 21:13, Robert Boehne wrote: I didn't think convenience libraries were meant to result in shared libs, just a bucket of object files with a convenient handle. Yes indeed. The problem is that I didn't want a convenience library, I did want a shared lib. Ralf's answer solved the problem exactly as I hoped. cheers, DaveK ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
On 19/03/2010 06:18, Ralf Wildenhues wrote:
[ ... snip ... ] The level of privileges required
for some executable program to accomplish its task may be designated by
the program developer by means of a manifest file (@pxref{Manifest
Files}), which may either be installed in the same directory alongside
the executable, or can be built directly in by adding the manifest file
as a binary resource in a Windows resource file (@pxref{Resource Files})
that is included in the executable's final link.[ ... snip ... ]
That's better, but it makes it sounds like the resource file is a
binary, and built directly in sounds unobvious to me. Is binary
resource a technical term? Would using just resource be enough?
Actually, I was wrong:
AFAIU, the resource file (*.rc) is a simple hand-written text file,
which may refer to the manifest file (like a .c file includes a header),
then gets compiled by windres to an object file and linked in like any
other object. Right?
Yep, that's basically it. The resource file defines objects from a certain
number of pre-defined categories, such as strings, icons and other small
bitmaps, and various struct-like things such as version infos; these are
compiled (along with some management data) into a .rsrc section that is then
linked into the exe.
A binary resource is a catch-all object type that just includes any old
arbitrary binary data you like, it's a bag-o-bytes.
However I misunderstood the docs I looked up. MS have defined a specialised
type of resource for manifests, you don't just throw them in as a blob, and
that means you just create a manifest resource type entry and include the
manifest xml data as a string directly within it; it doesn't refer to a
separate file on disk at all. So better wording would be:
... or can be built directly in by adding the XML contents of the file as a
manifest resource in a Windows resource file (@pxref{Resource Files}) that is
included ...
BTW, if the password is not given correctly, then will the program run
under lesser privileges or will it not run at all? I think we should
document that as well, because either outcome has implications for the
developer.
I don't have a handy installation to find out on. I would guess that if you
enter the password incorrectly it asks you to try again, just like a regular
windows log-on dialog, and if you click Cancel, the application doesn't
launch. I'll see if I can find some more solid info anywhere.
This is where I'm at now.
Looking good, apart from the above only one nit:
If your executable does not need elevated privileges, but happens to match any
of those strings, the OS will prompt for a password. If granted,
run the executable with greater privileges than an ordinary user
application is supposed to have; otherwise, the program will not be started.
There's a word or two gone missing between granted and run!
cheers,
DaveK
How to build a noinst_ but still shared library?
Hi all, Well, here I am again with another dumb n00b question. From the automake manual: Libtool convenience libraries are declared by directory-less variables such as `noinst_LTLIBRARIES', `check_LTLIBRARIES', or even `EXTRA_LTLIBRARIES'. So: how do you build a shared library in your make check run, without it ending up installed somewhere during make install? (In case it's relevant, the project is all flat in a single non-recursive Makefile, so I can't just e.g. force the subconfigure in tests/ to use a bogus $prefix choice under $objdir somewhere.) cheers, DaveK ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Can anyone think of a way to get circular dependencies between windows DLLs?
On 18/03/2010 18:57, Ralf Wildenhues wrote: Hi Dave, * Dave Korn wrote on Thu, Mar 18, 2010 at 02:49:35AM CET: Can I build an import library in the .libs/ subdir and leave an empty one by the same name in the parent dir and the -L paths will make sure that the one goes into the DLL link and the other ends up in the static archive? I wouldn't know how to do that without changing libtool. But I'm not sure I even understand: what do you mean by adding an empty library to a static archive? Even with an import library, adding to a static archive should be a no-op, no? g Nah, it was late on St. Patrick's night when I wrote that and I wasn't thinking straight. Of course the linker isn't involved in linking a static library. Duh me. So the -Wl, approach solves both aspects of the problem neatly in one. Just preparing to test some patches right now, thanks for the advice! cheers, DaveK ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
On 17/03/2010 17:14, Eric Blake wrote:
On 03/16/2010 04:24 AM, Dave Korn wrote:
On 16/03/2010 06:17, Ralf Wildenhues wrote:
Microsoft @sc{dos} and Windows systems. The @sc{gnu}
Should capitalise DOS and GNU.
@sc{} does the capitalization for you. This is correct texinfo usage.
Thanks, that's a new one to me. OTOH, the texinfo documentation for @sc
suggests that GNU is an acronym, and so I would think is DOS, so maybe that
tag should be used instead of sc.
cheers,
DaveK
Can anyone think of a way to get circular dependencies between windows DLLs?
Hi all, I have an interesting problem to try and solve: I need to create circularly-dependent shared libs using libtool on Windows(*). This is trivial on the ELF targets that libtool supports because you just leave undefined references in both the libraries, link them against each other, and the loader fixes it all up at runtime. On Windows we have the well-known restriction that you can't have undefined symbols in libraries at link time. Any imports from another library have to be resolved by linking against the import stub from the relevant import library. These import libraries are generated as a side-effect of linking the shared library DLL itself; so what libtool can't do on Windows is build two libraries that both refer to symbols from the other, because whichever one it tries to link first, the import library for the other hasn't been created yet. Fortunately that's not a problem in this particular case, because in one direction there aren't actually any undefined references that would cause linking to fail; what I'm trying to do is create an entirely artificial forced dependency(*) in that direction only, and if it wasn't for that this would just be a straightforward case of one library dependent on another. As a proof of concept, I created a dummy .def file containing the name of a single symbol from the DLL I wanted to create a dependency on, used dlltool to build an import library from that, and cut-and-pasted the libtool-generated final link line for the DLL that I wanted to have the dependency, adding the import library I had just built (using --whole-archive). This worked perfectly; I got a DLL which imported a symbol from the other DLL, and any application which linked against either DLL caused both to be loaded at runtime, which was my goal. The question, then, is this: can I get libtool to do this for me? More specifically, can I get libtool to do this for me, without having to modify it (or do anything else unsuitable for GCC stage 3)? I don't think I can get libtool to build the dummy import library for me as a libtool-controlled convenience library, so I think I'm left with just building the .a file as an ordinary target in my makefile and trying to persuade libtool to link it in, but I couldn't figure out how to do that. Libtool either complained about not knowing how to link against a static archive, or listed my bogus import library in the dependent_libs; I'm pretty sure I don't want it to do that, since this is a temporary build-time artifact only and will not be installed. I /think/ I tried every combination of using -limportlib vs. libimportlib.dll.a and of adding it or not to _LDADD vs. _DEPENDENCIES vs. _LDFLAGS, but I might have overlooked something, I'm not fully fluent in libtool-ese. An additional (minor) problem is whether I could get it to link this .a file only into the shared library and not the static archive (although I think it wouldn't matter if I can't avoid that, but I'd rather be tidy). Is this at all possible then? Just shove an arbitrary .a file into the final link of a libtool shared library DLL without libtool wanting to know anything about it? cheers, DaveK -- (*) - In order to simplify this post, I'd like to skip over the entire justification of /why/ I want to do this, and whether it wouldn't be better to adopt a different solution. Anyone interested in the gory details can read GCC PR42811, but for the purposes of discussion, let us just assume that this is indeed the correct and even best solution to the problem at hand. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Can anyone think of a way to get circular dependencies between windows DLLs?
On 17/03/2010 21:24, Ralf Wildenhues wrote: You can use '-Wc,', '-Wl,', '-Xcompiler ', or '-Xlinker ' to get command line arguments to by-pass libtool mangling and interpretation, and end up being passed to the compiler driver or the linker, respectively. The arguments may be ordered differently on the resulting command line, however. IIUC then the rest may be had by makefile rules? Thanks Ralf, I didn't know to try that; I'll give it a go and report back if it does the job. Can I build an import library in the .libs/ subdir and leave an empty one by the same name in the parent dir and the -L paths will make sure that the one goes into the DLL link and the other ends up in the static archive? cheers, DaveK ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
On 16/03/2010 06:17, Ralf Wildenhues wrote:
Microsoft @sc{dos} and Windows systems. The @sc{gnu}
Should capitalise DOS and GNU.
The Microsoft Vista version of Windows provides increased default
Should refer to Vista and all later versions.
and updating of system-wide software. The level of privileges required
for some executable program to accomplish its task may be designated by
the program developer by means of a manifest file (@pxref{Manifest
Files}) or a compiled-in Windows resource file (@pxref{Resource Files}),
among other possibilities, and among many other system-specific metadata
that may be added to these files, such as program icons.
This is slightly confusing, I don't think it quite makes it clear that
what's going on is that the manifest file can be put into the resource file.
How about something along the lines of ...
[ ... snip ... ] The level of privileges required
for some executable program to accomplish its task may be designated by
the program developer by means of a manifest file (@pxref{Manifest
Files}), which may either be installed in the same directory alongside
the executable, or can be built directly in by adding the manifest file
as a binary resource in a Windows resource file (@pxref{Resource Files})
that is included in the executable's final link.[ ... snip ... ]
Now, there exists [ ... snip ... ]
Now, unfortunately, [ ... snip ... ]
Now, @command{libtool} [ ... snip ... ]
That comes across a bit awkwardly. The explanation is correct in details,
just the wording needs a tweak. Apart from avoiding the repetition of 'Now,'
I'd also suggest rewording to this bit:
This means, if your executable happens to match any of
those strings, even if it has no need for elevated privileges otherwise,
will needlessly prompt for a password, and if granted, work under
super-user access.
Complex run-on sentence construction. How about just
[ ... snip ... ] If your executable does not need elevated privileges, but
happens to match any of those strings, the OS will needlessly prompt for a
password, and (if granted) run the executable with greater privileges than an
ordinary user application is supposed to have.[ ... snip ... ]
And maybe here:
It is possible to turn off this hack by means of a
manifest file or compiled-in resource.
... mention that you can indeed also turn it on (well, request elevated
privilege) for files that have names that /do not/ match the patterns listed
above.
cheers,
DaveK
Re: Extend libtool dll namespaces for mingw-w64
On 30/01/2010 14:56, Ralf Wildenhues wrote: web site, refer to this page, rebuild your binutils ld to automatically search for the changed prefix when it encounters -lfoo on the command Not binutils, I don't think: [1] My ld.info contains, speaking about cygwin, For instance, when ld is called with the argument `-lxxx' it will attempt to find, in the first directory of its search path, libxxx.dll.a xxx.dll.a libxxx.a xxx.lib cygxxx.dll (*) libxxx.dll xxx.dll before moving on to the next directory in the search path. (*) Actually, this is not `cygxxx.dll' but in fact is `prefi.dll', where `prefix' is set by the `ld' option `--dll-search-prefix=prefix'. In the case of cygwin, the standard gcc spec file includes `--dll-search-prefix=cyg', so in effect we actually search for `cygxxx.dll'. Yes; this relies entirely on the compiler's LINK_SPEC to pass the correct --dll-search-prefix, as far as I know; W64 team need to do the same with their compiler specs. It's not part of LD itself. cheers, DaveK ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
On 29/01/2010 01:10, JonY wrote: On 1/29/2010 04:07, Ralf Wildenhues wrote: Yes, GCC trunk uses that, but right now, -bindir for both 32bit and 64bit subsystems point to the same dir. Another solution it to stop installing DLLs to bindir and follow unix style installs into libdir, right beside the import libs, let the user set the PATH. That way, we don't need a bin32 and bin64 directory, but it does not prevent possible conflicts with 32bit mingw-w64 and mingw.org DLLs. This is GCC PR40125, and I don't suppose I'm going to be able to fix it before 4.5.0. Kai suggested we should leave them in gcc's private dir (which is where the language runtime import libs go, not libdir), but libdir is as good as any. I think that in all the focus on bitness, and whether or not it is necessary to separate 32-vs-64, has distracted from the very different issue of how we keep 32-bit MinGW DLLs from clashing with 32-bit MinGW-W64 DLLs. That is a situation *exactly* analagous to the Cygwin-vs-MinGW clash, and I think it fully justifies using a separate prefix. Although at some time in the future there may be a reunification between MinGW and MinGW-W64, at the moment they are effectively separate ABIs, and although it would probably mostly work to try interchanging them, we shouldn't. It's not going to be possible to educate the entire Windows-using fraternity into keeping tight control over their PATH settings. It's not how they work, and it's not how Windows encourages them to work. Windows users generally set their PATH through their GUI control panel and aren't in the habit of varying it on per-application basis. That's why we had to keep Cygwin DLLs and MinGW in a separate namespace; people simply _are_ going to have both in their PATH at the same time, and we just have to deal. (Windows doesn't help here by implicitly placing . at the front of your PATH for dll-search purposes either, and nor do we have a runpath to get us out of trouble; DLLs are searched by basename only.) So I think what I'd conclude is that MinGW-W64 should have its own prefix, but it should be the same one for 32-bit and 64-bit W64 DLLs. cheers, DaveK ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Roumen Petrov wrote: Dave Korn wrote: *Your suggestion to use realpath instead of abspath requires magic or time-travel before it is even possible, which is why I will waste no time on it.* Reading all above seems to my you mix mail threads and/or lists. Nonsense, I'm not engaged in conversation with you on any other list. This is the one and only threads and/or lists where someone is suggesting I try to use realpath on a directory before it is created; that requires time-travel or magic. :) :) :) Dave, you even don't understand what is wrong. No, I haven't got the faintest idea what's wrong, but whatever your problem is, it can't be solved by computer code. Go and read up about how 'configure' works and what a prefix is. Please, countdown before to post (hint: manual is libtool) . Hint: libtool is one tiny part of a huge interlocking system. cheers, DaveK
Re: [PATCH, take 5][cygwin|mingw] Control where win32 DLLs get installed.
Dave Korn wrote: libtool/ChangeLog: The paperwork arrived today and is in the post on its way back to GNU HQ. cheers, DaveK
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Roumen Petrov wrote: The calculation or relative path to dll is based on function XXX_abspath that may produce wrong results. No it doesn't. Like any function, it produces the correct results when given valid inputs, but if you give it bad input, you get GIGO. I suggest you go read the fine manual about the realpath and abspath functions, because until you understand the difference between these two functions you're just wasting everybody's time. *Your suggestion to use realpath instead of abspath requires magic or time-travel before it is even possible, which is why I will waste no time on it.* I'm concerned that we can't implement a working portable(cross-platform) relative path calculation. But that is exactly what I have done. It works, it is in portable code, it operates the same on all platforms. It has an implicit requirement that you do not pass it a path containing a symlink. As does *everything else* in autotools. What is better for dlname for installed la-file: absolute or relative path ? That you could even ask such a question demonstrates that you don't understand the subject you are pontificating about. Go and read up about how 'configure' works and what a prefix is. cheers, DaveK
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Ralf Wildenhues wrote:
Hi Dave,
sorry for making you go through another round.
:-/ That'll teach me to say unless there's anything else?
+pathcar=s,^/\([^/]*\).*$,\1,
+pathcdr=s,^/[^/]*,,
+removedotparts=s,/\(\.\(/\|$\)\)\+,/,g
+collapseslashes=s,/\+,/,g
\+ is a GNU sed extension, \{1,\} is Posix (two instances).
Nested \( \) are not portabled sed, neither are alternations \|.
Aaarrrgghh *headdesk* no alternations? That's ... just ... it's
not even boolean! Grrnashrollfoamgibber Damn you, ATT! Damn you, Sun!
*shakes fist at crowd of greying bearded sandal-wearing old programmers* See
you in hell, Unix-boys! pulls pin out of a negated character class and
laughs maniacally
Anchors $ inside groups are not portable.
The nesting probably works on most systems we care about, but if we can
avoid it then I'd prefer to do so.
Okeydokey, simplified the SED scripts.
+if test x$func_relative_path_tlibdir = x ; then
Please double-quote $func_relative_path_tlibdir. The rest of your patch
seems to cope with with spaces in file name components (even if the rest
of Libtool may not).
Woops, yes, that was the intention, missed that one. One more quick check
over all the quoting won't hurt while I'm at it.
+func_restore_path ()
+{
+ PATH=$save_PATH
No 'export PATH' here? (two instances)
So I reread the autoconf portable shell bit, found the bit about export, now
I know why it needs re-exporting each time it gets changed; will add the
missing directive.
+AT_CHECK([$LIBTOOL --mode=execute ./main$EXEEXT], [], [stdout])
Please use LT_AT_NOINST_EXEC_CHECK here, to avoid error when cross
compiling. Similar for the other executions of uninstalled programs.
(This macro is defined in tests/testsuite.at.)
Thanks for pointing me at it, can do.
+# Ensure libraries can be found on PATH, if we are on one
+# of the affected platforms, before testing the shared version.
+
+func_save_and_prepend_path $curdir/.libs
+AT_CHECK([$LIBTOOL --mode=execute ./.libs/main$EXEEXT], [], [stdout])
eval `$LIBTOOL --config | grep '^objdir='`
func_save_and_prepend_path $curdir/$objdir
LT_AT_NOINST_EXEC_CHECK(... $objdir/...)
Ah, thanks, that beats hard-coding .libs/.
I'm afraid the direct execution of programs below .libs may not work
everywhere. I'd have to check to be sure though. It's fine with me
if you run this particular test only on systems of interest to you.
I think it's easier to just make it install the test executable.
Also, gah! Can't run a program because it's in a subdirectory? What
kind of hare=brained system is that? Would it help if I gave -rpath $objdir
when linking main as well as for the libs?
+# In fact, prepending the PATH as above is superfluous on the windows
+# platforms that this feature is primarily aimed at, as the DLL search
+# path always includes the directory from which the app was launched.
+# To make sure it still works even when not side-by-side, we'll install
+# the main executable and execute it from there while the PATH still
+# points to the shared libs in the .libs subdir. On other platforms,
+# the rpaths we set at link time will guarantee it runs from the bindir.
+
+mkdir $curdir/bin
+AT_CHECK([$LIBTOOL --mode=install $lt_INSTALL main$EXEEXT
$curdir/bin/main$EXEEXT], [], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --mode=execute $curdir/bin/main$EXEEXT], [], [stdout])
This one should work without $LIBTOOL --mode=execute prepended, no?
I have no idea. I just copied the only other things in the testsuite that I
could identify as execution tests. What does it actually *do*?
In that case, you could use LT_AT_EXEC_CHECK here, again, to avoid
spurious failures when cross compile testing.
Point taken.
If you care about the fact that an installed program does not
accidentally require, or search for, a library in an uninstalled
location, then you can, after the mode=install but before the execution,
clean up the files in the build tree, or even put a poisoned library
into the build tree. I don't think either is necessary to do in this
test (at least the latter seems overkill, as we do it in other tests
already), but please decide for yourself.
Deleting the libs from the build tree seems easiest.
+AT_SETUP([bindir install tests])
+curdir=`pwd`
+for libdir in \
+$curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0 \
+$curdir/usr/lib/gcc/../gcc/.//i686-pc-cygwin/4.5.0/../../././//. \
+$curdir/usr/lib/ \
+$curdir/usr/lib \
+$curdir/baz \
+$curdir/baz/lib/ ;
Mini nit: this ; is not necessary. :-)
It's still valid, isn't it? I don't like to make my syntax in a way that
only works because of line breaks.
+ AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC -no-undefined -shared -o
libfoo.la $CPPFLAGS $CFLAGS $LDFLAGS foo.lo bar.lo baz.lo -rpath
$libdir],[0],[ignore],[ignore])
Please drop -shared, it should be unnecessary.
Ok, will do.
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Roumen Petrov wrote: I think that processing of '..' in a path is too naive. It will fail to produce correct results on filesystems with links. As I explained to Eric, this function implements 'abspath', not 'realpath', and given that we can't assume any of the directories even exist when we have to do this at link time, before installation, I don't see how we could hope to do any different. I think the whole of GNU configure expects the tree under $prefix/ to be real and there are a lot of other things that will break if you try to use symlinks to make the physical directory structure different from the apparent structure, for example gcc tries to execute ld by starting at the $prefix/lib/gcc/$target/$version directory where cc1 lives and invoking ../../../../bin/ld; if you've got symlinks in there that can't be ascended without ending up somewhere other than you expect, then the compiler isn't going to work. So I don't think this is likely to cause any problem except in really bizarre corner-cases where someone's already trying something dubious, is it? cheers, DaveK
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Ralf Wildenhues wrote: * Dave Korn wrote on Sun, Aug 16, 2009 at 06:26:11PM CEST: +AT_CHECK([$LIBTOOL --mode=install $lt_INSTALL main$EXEEXT $curdir/bin/main$EXEEXT], [], [ignore], [ignore]) +AT_CHECK([$LIBTOOL --mode=execute $curdir/bin/main$EXEEXT], [], [stdout]) This one should work without $LIBTOOL --mode=execute prepended, no? I have no idea. I just copied the only other things in the testsuite that I could identify as execution tests. What does it actually *do*? Run an installed program. Installed programs ought to run without $LIBTOOL prepended. Did you mean Run an *un*installed program in the first part of that? I'll assume so. Out of curiosity, which of the systems of interest creates a libfoo.so.0 file? Linux. But you're not interested in testing GNU/Linux with $bindirneeded. Neither any of the other unices, which might not have a libfoo.so.0, but instead a libfoo.a (shared library! sic! on AIX) or a libfoo.0.so or libfoo.so.0.0 or whatnot. So make life easy here, and drop all the .so thingy tests, you don't want them here. Thanks. But I do want to make sure the file went to the right place, or at the very least, that it did *not* go to the -bindir. Hmm. I can't easily use a pattern match either as it might match more than one file and confuse the test -f syntax. Guess I'll have to `ls *foo*0*` them and test -z the output, that should work. What if that is a symlink rather than a plain file (test -f only tests for plain files)? It is. The test still passes. H. better take a closer look at that. (And use the full so.0.0.0 name in the test). Yeah, that's due to $bindirneeded. But that just makes it test -f for the same name in a different directory, so it still ought to fail. It turns out that, at least for bash on my Fedora 10 VM, test -f works for symlinks: [da...@ubique .libs]$ if test -f libfoo.so.0 ; then echo yes ; else echo no ; fi yes [da...@ubique .libs]$ if test -f libfoo.so.0.0.0 ; then echo yes ; else echo no ; fi yes [da...@ubique .libs]$ ls -la libfoo.so.0* lrwxrwxrwx 1 davek davek 15 2009-08-16 20:55 libfoo.so.0 - libfoo.so.0.0.0 -rwxrwxr-x 1 davek davek 5425 2009-08-16 20:55 libfoo.so.0.0.0 [da...@ubique .libs]$ echo $BASH_VERSION 3.2.39(1)-release [da...@ubique .libs]$ Weird. Anyway, I won't rely on it. cheers, DaveK
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Dave Korn wrote: Guess I'll have to `ls *foo*0*` them and test -z the output, that should work. Nope, may have whitespace. Is checking the return status of ls portable? cheers, DaveK
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Roumen Petrov wrote:
Dave Korn wrote:
Roumen Petrov wrote:
I think that processing of '..' in a path is too naive. It will fail to
produce correct results on filesystems with links.
this function implements 'abspath', not 'realpath',
^^^
and given that we can't assume any of the directories even exist when
we have to do this at link time, before installation,
^
You may test you function with following example:
No thanks, I don't think I'll bother. I understand perfectly well what the
problem is with symlinks, but what you seem to overlook is that there is no
possible way of knowing whether any path component will be a real directory or
a symlink *before it is even created*.
Sure.
Currently for gcc 4.4.0 (target i486-mingw32 build ${ARCH}-pc-linux) non
prefixed binaries from PREFIX/TARGET/bin don't work for me. As
example gcc can't find cc1. May be is same issue.
Yes, like I told you, the whole of GNU autotools and configure and
everything assumes that you won't be messing around with symlinks in your
$prefix structure like this. What you are doing is unsupported.
To resolve issue I use following additional links:
# cd $PREFIX
# l ./i486-mingw32/lib/gcc
lrwxrwxrwx 1 ./i486-mingw32/lib/gcc - ../../lib/gcc/
# l ./i486-mingw32/libexec
lrwxrwxrwx 1 ./i486-mingw32/libexec - ../libexec/
So I don't think this is likely to cause any problem except in really
bizarre corner-cases where someone's already trying something dubious,
is it?
So to me function like XX_abspath has to work.
Since what you want is impossible in the general case, I'm not going to put
any effort into making your system work. If you want to implement this
entirely new feature, you will have to patch autoconf, automake, gcc, libtool,
and everything else yourself.
cheers,
DaveK
[PATCH, take 5][cygwin|mingw] Control where win32 DLLs get installed.
/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -1129,6 +1129,8 @@ The following components of LINK-COMMAND are treated specially: -all-static do not do any dynamic linking at all -avoid-versiondo not add a version suffix if possible + -bindir BINDIRspecify path to binaries directory (for systems where +libraries must be found in the PATH setting at runtime) -dlopen FILE \`-dlpreopen' FILE if it cannot be dlopened at runtime -dlpreopen FILE link in FILE and add its symbols to lt_preloaded_symbols -export-dynamic allow symbols from OUTPUT-FILE to be resolved with dlsym(3) @@ -3659,6 +3661,7 @@ func_mode_link () new_inherited_linker_flags= avoid_version=no +bindir= dlfiles= dlprefiles= dlself=no @@ -3751,6 +3754,11 @@ func_mode_link () esac case $prev in + bindir) + bindir=$arg + prev= + continue + ;; dlfiles|dlprefiles) if test $preload = no; then # Add the symbol object into the linking commands. @@ -4012,6 +4020,11 @@ func_mode_link () continue ;; + -bindir) + prev=bindir + continue + ;; + -dlopen) prev=dlfiles continue @@ -7704,9 +7717,27 @@ EOF fi $RM $output # place dlname in correct position for cygwin + # In fact, it would be nice if we could use this code for all target + # systems that can't hard-code library paths into their executables + # and that have no shared library path variable independent of PATH, + # but it turns out we can't easily determine that from inspecting + # libtool variables, so we have to hard-code the OSs to which it + # applies here; at the moment, that means platforms that use the PE + # object format with DLL files. See the long comment at the top of + # tests/bindir.at for full details. tdlname=$dlname case $host,$output,$installed,$module,$dlname in - *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll) tdlname=../bin/$dlname ;; + *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll) + # If a -bindir argument was supplied, place the dll there. + if test x$bindir != x ; + then + func_relative_path $install_libdir $bindir + tdlname=$func_relative_path_result$dlname + else + # Otherwise fall back on heuristic. + tdlname=../bin/$dlname + fi + ;; esac $ECHO $output \ # $outputname - a libtool library file diff --git a/tests/bindir.at b/tests/bindir.at new file mode 100644 index 000..e0e1b05 --- /dev/null +++ b/tests/bindir.at @@ -0,0 +1,380 @@ +# bindir.at - Test the -bindir option +# +# Copyright (C) 2009 Free Software Foundation, Inc. +# Written by Dave Korn, 2009 +# +# This file is part of GNU Libtool. +# +# GNU Libtool is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# GNU Libtool is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with GNU Libtool; see the file COPYING. If not, a copy +# can be downloaded from http://www.gnu.org/licenses/gpl.html, +# or obtained by writing to the Free Software Foundation, Inc., +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + + + +# In this testcase, and in the chunk of code that makes use +# of $bindir in ltmain.m4sh, we would very much have liked to +# automatically decide which systems require dynamically-loaded +# libraries to be installed to a directory in $PATH according +# to the libtool properties that tell us that the system provides +# no way to hard-code library paths into executables, and also +# has no $shlibpath_var independent of the PATH variable, in +# Ralf's words. But it turns out this is not possible, as:- +# +# * Dave Korn wrote on Fri, Aug 14, 2009 at 04:30:27AM CEST: +# Ralf Wildenhues wrote: +# +# But in this particular case, I would argue that either you look at +# the libtool variables shlibpath_var and hardcode_action for PATH +# and unsupported. +# +# On Cygwin, $hardcode_action = immediate in the generated libtool +# script. Did you perhaps mean $hardcode_shlibpath_var, which is indeed +# unsupported? +# +# Oh brother, yes, I forgot about those bogus hardcode_libdir_flag_spec +# settings. They fool _LT_LINKER_HARDCODE_LIBPATH. I don't remember whether +# they were needed in order to not break some semantics in ltmain (they +# probably were). +# +# Anyway, $hardcode_action = immediate is definitely wrong, but fixing that +# now is also way out of scope of this patch. So I guess we need to stick to +# host matching in the code, and work out
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
Ralf Wildenhues wrote:
in addition to what Eric already documented:
* Dave Korn wrote on Fri, Aug 14, 2009 at 01:34:18PM CEST:
Still finishing it off and getting it tested, but while that's going,
here's
a preview of the path canonicalisation function as I've got it so far; let me
know if I've done any major no-nos please!
Do you cope with paths starting with // (these can be special on Cygwin,
you may not remove the second / in that case)? (If anything, this is
only a rather minor no-no however, and I have no idea whether we treat
it consistently elsewhere in libtool.)
Hah. I collapse them of course. Doh. I'll see how I can preserve them.
The other possible problem is DOS-style paths. I don't know if libtool is
supposed to handle them or not. It certainly looks like
func_dirname_and_basename would fall down badly on them, but I don't know if
that's just a happenstance of the way it got autogenerated on my platform
where they aren't used? I couldn't find anything in the manual referring to
drive letters.
# func_normal_abspath path
Capitalize PATH here, please. Maybe also s/PATH/FILE/ throughout the
comment, to avoid mistaking it with the $PATH environment variable?
Will take the latter option.
# Remove doubled-up and trailing slashes, . path components,
# and cancel out any .. path components in PATH.
# value returned in $func_normal_abspath_result
Missing a statement that an absolute path is returned, that would be
nice.
Will add. (The name of the function is supposed to be a hint, but it can't
hurt to be explicit!)
One would hope for a followup patch that factorizes all the forks
in this function for SUSv3 shells that provide ${var##...} etc.
Otherwise, if this function is used more than once per libtool
invocation, it will be a major speed bump in a typical build.
(IOW, you don't need to address this, but it ought to be looked at;
I might do it sometime.)
Thanks, I still haven't learned all the internal structure of libtool and
wouldn't know how to do that without a bunch more research.
Respin is nearly complete now, just these minor tweaks to get through and
give it some testing. More later.
cheers,
DaveK
[PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
\`-dlpreopen' FILE if it cannot be dlopened at runtime -dlpreopen FILE link in FILE and add its symbols to lt_preloaded_symbols -export-dynamic allow symbols from OUTPUT-FILE to be resolved with dlsym(3) @@ -3659,6 +3661,7 @@ func_mode_link () new_inherited_linker_flags= avoid_version=no +bindir= dlfiles= dlprefiles= dlself=no @@ -3751,6 +3754,11 @@ func_mode_link () esac case $prev in + bindir) + bindir=$arg + prev= + continue + ;; dlfiles|dlprefiles) if test $preload = no; then # Add the symbol object into the linking commands. @@ -4012,6 +4020,11 @@ func_mode_link () continue ;; + -bindir) + prev=bindir + continue + ;; + -dlopen) prev=dlfiles continue @@ -7704,9 +7717,27 @@ EOF fi $RM $output # place dlname in correct position for cygwin + # In fact, it would be nice if we could use this code for all target + # systems that can't hard-code library paths into their executables + # and that have no shared library path variable independent of PATH, + # but it turns out we can't easily determine that from inspecting + # libtool variables, so we have to hard-code the OSs to which it + # applies here; at the moment, that means platforms that use the PE + # object format with DLL files. See the long comment at the top of + # tests/bindir.at for full details. tdlname=$dlname case $host,$output,$installed,$module,$dlname in - *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll) tdlname=../bin/$dlname ;; + *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll) + # If a -bindir argument was supplied, place the dll there. + if test x$bindir != x ; + then + func_relative_path $install_libdir $bindir + tdlname=$func_relative_path_result$dlname + else + # Otherwise fall back on heuristic. + tdlname=../bin/$dlname + fi + ;; esac $ECHO $output \ # $outputname - a libtool library file diff --git a/tests/bindir.at b/tests/bindir.at new file mode 100644 index 000..5e3dfd0 --- /dev/null +++ b/tests/bindir.at @@ -0,0 +1,374 @@ +# bindir.at - Test the -bindir option +# +# Copyright (C) 2009 Free Software Foundation, Inc. +# Written by Dave Korn, 2009 +# +# This file is part of GNU Libtool. +# +# GNU Libtool is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# GNU Libtool is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with GNU Libtool; see the file COPYING. If not, a copy +# can be downloaded from http://www.gnu.org/licenses/gpl.html, +# or obtained by writing to the Free Software Foundation, Inc., +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + + + +# In this testcase, and in the chunk of code that makes use +# of $bindir in ltmain.m4sh, we would very much have liked to +# automatically decide which systems require dynamically-loaded +# libraries to be installed to a directory in $PATH according +# to the libtool properties that tell us that the system provides +# no way to hard-code library paths into executables, and also +# has no $shlibpath_var independent of the PATH variable, in +# Ralf's words. But it turns out this is not possible, as:- +# +# * Dave Korn wrote on Fri, Aug 14, 2009 at 04:30:27AM CEST: +# Ralf Wildenhues wrote: +# +# But in this particular case, I would argue that either you look at +# the libtool variables shlibpath_var and hardcode_action for PATH +# and unsupported. +# +# On Cygwin, $hardcode_action = immediate in the generated libtool +# script. Did you perhaps mean $hardcode_shlibpath_var, which is indeed +# unsupported? +# +# Oh brother, yes, I forgot about those bogus hardcode_libdir_flag_spec +# settings. They fool _LT_LINKER_HARDCODE_LIBPATH. I don't remember whether +# they were needed in order to not break some semantics in ltmain (they +# probably were). +# +# Anyway, $hardcode_action = immediate is definitely wrong, but fixing that +# now is also way out of scope of this patch. So I guess we need to stick to +# host matching in the code, and work out a separate fix for the setting of +# $hardcode_libdir_flag_spec. +# +# So alas we punt for now, and just hardcode the relevant OSs that require +# this functionality. That's Cygwin, MinGW and CeGCC for now; see the case +# statement in libtool.m4sh around where the 'tdlname' variable is set. + + +# Verify compiling works, and skip remaining tests if not. +# + +AT_SETUP([bindir compile check]) + +AT_DATA([simple.c
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
Ralf Wildenhues wrote:
So I guess we need to stick to host matching in the code,
Shame, but at least it makes my life slightly easier ;-)
Still finishing it off and getting it tested, but while that's going, here's
a preview of the path canonicalisation function as I've got it so far; let me
know if I've done any major no-nos please!
cheers,
DaveK
pathcar=s,^/\([^/]*\).*$,\1,
pathcdr=s,^/[^/]*,,
removedotparts=s,/\(\.\(/\|$\)\)\+,/,g
collapseslashes=s,/\+,/,g
# func_normal_abspath path
# Remove doubled-up and trailing slashes, . path components,
# and cancel out any .. path components in PATH.
# value returned in $func_normal_abspath_result
func_normal_abspath ()
{
# Start from root dir and reassemble the path.
func_normal_abspath_result=
func_normal_abspath_tpath=$1
case $func_normal_abspath_tpath in
)
# Empty path, that just means $cwd.
func_stripname '' '/' `pwd`
func_normal_abspath_result=$func_stripname_result
return
;;
/*)
# Absolute path, do nothing.
;;
*)
# Relative path, prepend $cwd.
func_normal_abspath_tpath=`pwd`/$func_normal_abspath_tpath
;;
esac
# Cancel out all the simple stuff to save iterations.
func_normal_abspath_tpath=`$ECHO $func_normal_abspath_tpath | $SED \
-e $removedotparts -e $collapseslashes`
# We want the path to end with a slash for ease of parsing, and
# doubled-up slashes won't hurt us here, so just add one on.
func_normal_abspath_tpath=$func_normal_abspath_tpath/
while :; do
func_normal_abspath_tcomponent=`$ECHO $func_normal_abspath_tpath | $SED \
-e $pathcar`
func_normal_abspath_tpath=`$ECHO $func_normal_abspath_tpath | $SED \
-e $pathcdr`
# Figure out what to do with it
case $func_normal_abspath_tcomponent in
)
# Trailing empty path component, ignore it.
;;
..)
# Parent dir; strip last assembled component from result.
func_dirname $func_normal_abspath_result
func_normal_abspath_result=$func_dirname_result
;;
*)
# Actual path component, append it.
func_normal_abspath_result=$func_normal_abspath_result/$func_normal_abspath_tcomponent
;;
esac
# Processed it all yet?
if test $func_normal_abspath_tpath = / ; then
# If we ascended to the root using .. the result may be empty now.
if test -z $func_normal_abspath_result ; then
func_normal_abspath_result=/
fi
break
fi
done
}
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
Eric Blake wrote: Cancelling out .. is wrong for 'symlink/..', when symlink does not necessarily point to a working directory exactly one level down. (True, cygwin does not implement POSIX semantics here, and cancels out foo/.. behind your back rather than properly resolving foo, but this function will need to work on all other systems that do it correctly). This is abspath, not realpath; it doesn't follow symlinks. It has to work before install time, there's no guarantee that any of the paths even exist. func_normal_abspath_tpath=$1 Double-quoting not necessary here - variable assignment is already in a quoted context, and quotes are only needed to protect metacharacters. case $func_normal_abspath_tpath in Likewise - the case argument is already in a double-quoted context. Ok, but is it harmful? I just prefer to quote always for simplicity and AFAIK it can't hurt (in an ordinary direct execution context like this, it might be different if I was assigning these commands as strings to variables and trying to exec them later.) ) # Empty path, that just means $cwd. func_stripname '' '/' `pwd` Can we rely on $PWD instead of forking a process? I don't know if it's supported by all the shells we have to support. I'm not too concerned with optimising the hell out of this, I want robustness first, and it's not something that I think should need to be used more than a couple of times during any given libtool invocation so I hope it's not a significant overhead. func_normal_abspath_result=$func_stripname_result return ;; /*) # Absolute path, do nothing. Do we want to cater to DOS style absolute paths? [a-z]:\\ I don't, personally. Does anything else in libtool handle them? Does libtool run on djgpp? Eurgh, that's going to make life horribly complicated. I'm tempted to just bang a wrapper around the current function that spots a dos path, strips off the driveletter-colon, converts to forward slashes, lets the current code handle it as if it were a posix path, then converts the slashes back and stitches the driveletter back on. ;; esac # Cancel out all the simple stuff to save iterations. func_normal_abspath_tpath=`$ECHO $func_normal_abspath_tpath | $SED \ -e $removedotparts -e $collapseslashes` I thought we were trying to move away from $ECHO and instead use the shell functions. I don't know, I copied func_dirname_and_basename. I thought there's a problem about backslashes being interpreted by some shell echos even in the absence of -e? And you have a portability no-no, documented in the autoconf manual: a=`` is non-portable, but can always be replaced by the portable: a=`` See why I don't like spurious around variable assignments? Ah, now I do. Ok, but is some nice clear list of where you should and shouldn't quote anywhere? As far as I can tell you have to memorize the entire bash manual and then infer what to do from all the overlapping sets of expansions and contexts and rules. Then you have to to the same for all the other shells we're supposed to support. Then you have to infer a set of lowest-common-denominator rules from all of that. # We want the path to end with a slash for ease of parsing, and # doubled-up slashes won't hurt us here, so just add one on. func_normal_abspath_tpath=$func_normal_abspath_tpath/ while :; do func_normal_abspath_tcomponent=`$ECHO $func_normal_abspath_tpath | $SED \ -e $pathcar` func_normal_abspath_tpath=`$ECHO $func_normal_abspath_tpath | $SED \ -e $pathcdr` Nit - I'd break these long lines at |, not after $SED, so that the entire sed command is on a single line. I took my cue from func_quote_for_expand, which made me think it would be at least acceptable to do it this way, but if you're looking for a convention, the libtool convention appears by overwhelming consensus to be not to wrap ECHO ... | SED at all, even if the line is really long. $ grep -R 'ECHO.*SED' libltdl/ | wc -l 591 $ grep -R '| \$SED \\' libltdl/ | wc -l 24 $ cheers, DaveK
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
Eric Blake wrote: I think it's as simple as: And beyond that, it's just lots of practice. I agree that it often feels like you have to memorize loads of information to write portable shell, but at least these public reviews catch a lot of the pitfalls. Your cheat sheet will come in very handy :) Thanks! cheers, DaveK
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
Ralf Wildenhues wrote:
Hello Dave,
* Dave Korn wrote on Tue, Aug 11, 2009 at 09:07:12AM CEST:
Well, the bindir option exists only to support PE DLLs,
Bzzt. First error. If libtool provides -bindir, then it should accept
it on every system, [ ... ] Of course on non-PE
systems, it should just ignore the option silently.
That's exactly what it does already, as I thought I mentioned upthread.
So it's only the PE-specific bits of the test that should be skipped on
systems where they don't apply.
Thus, bindir.at is a sensible name.
I can rename it and adjust the tests so they run on all platforms, but make
sure the library /doesn't/ get installed to bindir on non-PE platforms. Ok?
Do you intend for Automake to pass
-bindir to libtool --mode=link invocations automatically (maybe for
foo_LTLIBRARIES with foo not equal to lib or libexec)?
I intend the maintainer to trivially add -bindir $(bindir) anywhere in
their makefiles that they would be adding -no-undefined to cause DLLs to be
built. Sure I mentioned that one already, didn't I?
* Dave Korn wrote on Tue, Aug 11, 2009 at 10:35:28AM CEST:
All rebuilt OK. Checked docs with make dvi info pdf and viewing the
generated file. Testsuite re-run is still in progress, but I already checked
that the new tests all still pass, so unless I post back saying otherwise in
the
next couple of hours, assume the lot completed without regressions.
Tested on what system(s)?
i686-pc-cygwin. Could do a linux run as well if you like.
BTW, even if the part going into GCC is covered by your GCC assignment,
the rest is still sufficiently nontrivial to warrant an assignment.
Gah, of course, forgot about the testcase. Oh well, I didn't delay sending
off for the paperwork based on that theory, so we've not lost any time.
diff --git a/Makefile.am b/Makefile.am
old mode 100644
new mode 100755
Your files suffer from mode changes. They are of course not acceptable,
though I understand they are a w32 artifact. Can git be made to ignore
them for you?
I have no idea what's going on here. The modes of the files haven't changed
a bit according to 'ls', so cygwin git must be acting up. If I was to end up
applying the patch myself I'd probably have to check out libtool on a linux
box and commit it there.
tests/bindir.at, as already noted above; and as this is about
'libtool' (the script) API, please sort it alongside the other API
tests, preferably before or after cwrapper.at. Thanks.
Okeydokey; couldn't tell if there was a grouping and ordering in that list
or not.
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1376,6 +1376,15 @@ Tries to avoid versioning (@pxref{Versioning}) for
libraries and modules,
i.e.@: no version information is stored and no symbolic links are created.
If the platform requires versioning, this option has no effect.
+...@item -bindir
+When linking a DLL for Windows or another PE platform, this option tells
What does this have to do with PE?
PE is the object file format. There is no other object file format that has
DLLs, and no DSOs other than DLLs require installation to $PATH. It would
seem strange to suggest that this would work with ELF DLLs on Linux, for
example, since there are no such things!
All this is about is that there is
no real, independent $shlibpath_var beside PATH. I'm OK with mentioning
that Windows is the sole current user of this, but please let's word
this in a way that doesn't require us to change the interface if some
other system requires it, too. Ideally, neither the text.
I really and honestly cannot imagine any other possible use case for this
functionality. Still, if you want to suggest some more generic wording, just
tell me what you'd like it to say and I'll paste it in.
+# func_relative_path libdir bindir
+# generates a relative path from LIBDIR to BINDIR, intended
+# for supporting installation of windows DLLs into -bindir.
gnulib-tool has a function func_relativize. Can we just reuse that
(and make it fast)? Failing that, did you write this function from
scratch or took it from anywhere else.
I wrote it from scratch, then Chuck showed me how to do the shell script
portability stuff on this list. The tests cover all corner-cases and it works
and has no conceivable copyright or licensing snags. I think those are
reasonable justifications to just use it as-is.
I don't see any reason this function should be written specific to
libdir and bindir. There are other file names that may usefully be
relativized, so the function should be as general as possible, and use
generic names, too.
Sure; I just picked those names as indicative, not normative, examples of
usage. How about I change them to destdir and srcdir?
+# call:
+# func_dirname:
+# func_dirname file append nondir_replacement
Why do you repeat the descriptions of these functions here again?
That's not normally done elsewhere
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
Ralf Wildenhues wrote:
* Ralf Wildenhues wrote on Thu, Aug 13, 2009 at 08:23:22AM CEST:
* Dave Korn wrote on Tue, Aug 11, 2009 at 09:07:12AM CEST:
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1376,6 +1376,15 @@ Tries to avoid versioning (@pxref{Versioning}) for
libraries and modules,
i.e.@: no version information is stored and no symbolic links are created.
If the platform requires versioning, this option has no effect.
+...@item -bindir
+When linking a DLL for Windows or another PE platform, this option tells
What does this have to do with PE? All this is about is that there is
no real, independent $shlibpath_var beside PATH.
Erm, what I meant was that: this system provides no way to hard-code
library paths into executables, and also has no $shlibpath_var
independent of the PATH variable. Sorry about that.
Ah, see what you mean now; any other system with those properties would need
to have the libraries installed into a bindir where they could be found. Do
you know of any such systems off the top of your head?
You don't test paths with a '../' component in it. I thus assume they
won't work with your implementation (they work with gnulib-tool's).
These components often occur within GCC (haven't checked whether for
your particular situation, but I'd wonder why they shouldn't).
Good point. I'll add some and see what happens and fix any bugs arising
before I post the respin. I'd better check for './' components too.
cheers,
DaveK
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
Peter Rosin wrote: Missed this before, sorry. But since it is a well known fact that exporting variables from libraries are bad and should be avoioded, can we please stop adding more of that practice to the test suite? There is enough of it already and in case it fails, other failures might be hidden. It is? I didn't know that. I'll function-ify them. cheers, DaveK
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
Ralf Wildenhues wrote:
Yeah, I was merely arguing for the testsuite file name; sorry for the
confusion.
NP. Renamed to bindir.at.
I can rename it and adjust the tests so they run on all platforms, but make
sure the library /doesn't/ get installed to bindir on non-PE platforms. Ok?
Why would that additional test be necessary?
The general idea (however poorly executed) is that the test suite should
need as little adjustment as possible when we add support for new
platforms. Likewise, ltmain should not require much adjustment except
to accommodate actually new semantics; only libtool.m4 and ltdl.m4
really ought to carry all the system-specifics, and they should be
transported into the libtool script through the bunch of variables.
Yes, this idea is pretty poorly executed ATM.
But in this particular case, I would argue that either you look at the
libtool variables shlibpath_var and hardcode_action for PATH and
unsupported. And even then, I wouldn't really want to check for
presence of a particular file in $bindir, but I'd check whether a
program executable installed in $bindir, and linked against a library
(that should have its DLL installed in $bindir on applicable systems)
will start and run correctly. Written this way, however, you don't
need to delimit this particular test to any subset of platforms: things
will work on any other system, too, by way of libtool linking semantics.
Okay, I get what you mean. I agree with the first part (using shlibpath_var
and hardcode_action rather than tests of specific OSs), but I beg to differ
about the second. Checking if the program starts and runs correctly isn't
quite the same thing as checking if the parts were installed precisely where
the application coder instructed libtool to install them. It's an indirect
test, and for instance would false positive if someone on a windows platform
had /lib in their PATH. There might also be platforms where it didn't matter
functionally which of /bin and /lib a library got installed into, but there is
a packaging standard that says what goes where. Now, okay we can always reset
the PATH for the test, but if we're trying to do something that works as-is
for unanticipated future systems, could we ever be sure we'd caught every
environment variable or whatever that might make this indirect test produce a
false result?
For these reasons, I'd still prefer to test that the precise files we expect
get installed to the precise locations we require. Doing it that way (but
with the first part of your suggestion) would still be fully cross-platform
and future-friendly, wouldn't it?
Yes, you mentioned that. What I meant was a followup semantic change
in Automake. Assume a Makefile.am with
[ ... ]
We have (1) now. With (2), arbitrary --bindir and --libdir values
passed to configure by the user would be handled as well. The question
is whether there can be cases when a developer would *not* want -bindir
to be passed automatically.
What do you think? Even if there are such cases, we could arrange for
automake to output the -bindir before expanding $(LDFLAGS), so that it
would be overridable.
The honest answer is I just haven't thought that far ahead yet. I've only
been thinking of this option as a partner to -no-undefined, but you've
convinced me it might have relevance to a broader range of platforms. In that
context, it quite possibly would make sense for Automake to start adding it
automatically. But I haven't thought much about it yet.
I think it would be good to see test results for MinGW and GNU/Linux,
but it's sufficient to run the new tests only,
make check-local TESTSUITEFLAGS='-v -d -x -k bindir'
or so, depending on how you name your tests. (I can run these tests.)
Thanks, I'll take you up on that offer when the respin is complete.
diff --git a/Makefile.am b/Makefile.am
old mode 100644
new mode 100755
Your files suffer from mode changes.
I found a workaround. I think the perm changes were in non-unixy parts of
the ACL and caused by using a windows native editor. Copying correct perms
across from one of the other files in the same directory using 'chmod
--reference=...' shuts git up about the perms.
Certainly. My (arguably weak) point is that the Libtool manual is
pretty generic; there is currently literally no mention of the terms PE
or COFF at all, not even DLL is explained (note though that there is a
pending patch from Chuck that documents some w32-specific issues). It
simply seems a bit of a jump to start off this way. What about
something like
Pass the absolute name of the directory for installing executable
programs (@pxref{Directory Variables, , standards, The GNU Coding
Standards}). @command{libtool} may use this value to install shared
libraries there on systems that do not provide for any library
hardcoding and use the directory of a program and the @env{PATH}
variable as library search
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
Dave Korn wrote: +# func_relative_path libdir bindir gnulib-tool has a function func_relativize. Can we just reuse that (and make it fast)? Sure. However, if you want something that works with ../, then the gnulib-tool code is worth looking at. Just a suggestion, you know. I'll write something to pre-condition the paths (i.e. remove '.' components and cancel out 'component/..' pairs, remove any doubled-up slashes and trim any trailing one) and make it a separate func, it might come in handy elsewhere. Re that, BTW: can I use shell array variables portably? I'm guessing not, but it would simplify the design slightly if there was a way. cheers, DaveK
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
Tim Rice wrote: On Thu, 13 Aug 2009, Dave Korn wrote: Re that, BTW: can I use shell array variables portably? I'm guessing not, but it would simplify the design slightly if there was a way. No, array variables are not portable. g Sheer optimisim on my part. Thanks for the reply. cheers, DaveK
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
Ralf Wildenhues wrote: Seems ok. Thanks for persevering. NP :) OK. Well, can we compromise on _also_ having an executability test? There are always so many things that can go wrong for execution, that it is nonetheless useful to try that out, and for that, to have an executable that calls a function from the library. Absolutely fine by me; I'll code it that way. cheers, DaveK
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
Ralf Wildenhues wrote: But in this particular case, I would argue that either you look at the libtool variables shlibpath_var and hardcode_action for PATH and unsupported. On Cygwin, $hardcode_action = immediate in the generated libtool script. Did you perhaps mean $hardcode_shlibpath_var, which is indeed unsupported? cheers, DaveK
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
Dave Korn wrote: Now we twiddle our thumbs and wait for the paperwork, I guess! Hmm. Or potentially not. I just submitted the patch (backported to GCC's forked libtool) to the gcc-patches list(*). As far as I understand it, that means I have now assigned my copyright in the patch to the FSF via my GCC assign; or possibly I have expressed a willingness to assign my copyright which would be completed by the patch being approved and committed; but either way, the FSF now already is or is about to become the proper legal owner of the copyright, no? cheers, DaveK -- (*) - http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00661.html
Re: [PATCH+Assign request][cygwin|mingw] Control where win32 DLLs get installed.
Peter Rosin wrote: I think the new file tests/win32.at has a too generic name. And what if some non-win32 platform needs this? I think the test should be named tests/bindir.at (or inst-bindir.at) since that is what is tested. How about pe-dll.at? You also enable the code in ltmain for *cegcc*, but you skip the test. Oops, oversight; I'll enable it in the respin, thanks for noticing. cheers, DaveK
Re: [PATCH+Assign request][cygwin|mingw] Control where win32 DLLs get installed.
Peter Rosin wrote: Den 2009-08-11 08:50 skrev Dave Korn: Peter Rosin wrote: I think the new file tests/win32.at has a too generic name. And what if some non-win32 platform needs this? I think the test should be named tests/bindir.at (or inst-bindir.at) since that is what is tested. How about pe-dll.at? That is also very wide and as bad as win32.at, if you ask me. Many tests would belong under that name. Why do you feel the need to qualify the name of the test with some platform marker? You are testing if the new bindir option works as intended, I think that should be where you are coming from when naming the test. Well, the bindir option exists only to support PE DLLs, which have special installation needs, and I thought I'd make the name slightly generic because I figured future DLL-related tests could go there too. So Win32 is definitely too narrow, but I think pe-dll is about right. Unless that is it's not worth naming it with an eye to future expansion because there's no concern about proliferation of .at files and a policy of trying to have lots of small single-purpose test files rather than big collective ones, in which case how about pe-dll-inst-bindir.at? ;-) cheers, DaveK
Re: [PATCH+Assign request][cygwin|mingw] Control where win32 DLLs get installed.
Charles Wilson wrote:
So, here's the revised function (w/o the varname uglification):
*) func_dirname $tlibdir
tlibdir=${func_dirname_result}
if test x$tlibdir = x ; then
# Have to descend all the way to the root!
func_relative_path_result=../$func_relative_path_result
+ func_relative_path_tcancelled=$func_relative_path_tbindir
break
fi
:-) Hooray for test suites!
cheers,
DaveK
[PATCH, take 2][cygwin|mingw] Control where win32 DLLs get installed.
to the root!
+ func_relative_path_result=../$func_relative_path_result
+ func_relative_path_tcancelled=$func_relative_path_tbindir
+ break
+ fi
+ func_relative_path_result=../$func_relative_path_result
+ ;;
+esac
+ done
+
+ # Now calculate path; take care to avoid doubling-up slashes.
+ func_stripname '' '/' $func_relative_path_result
+ func_relative_path_result=$func_stripname_result
+ func_stripname '' '/' $func_relative_path_tcancelled
+ func_relative_path_result=${func_relative_path_result}${func_stripname_result}
+
+ # Normalisation. If bindir is libdir, return empty string,
+ # if subdir return string beginning './', else relative path
+ # ending with a slash; either way, target file name can be
+ # directly appended.
+ if test -z $func_relative_path_result; then
+func_relative_path_result=./
+ else
+func_stripname './' '' $func_relative_path_result/
+func_relative_path_result=$func_stripname_result
+ fi
+}
+
# The name of this program:
func_dirname_and_basename $progpath
progname=$func_basename_result
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
old mode 100644
new mode 100755
index ebd3909..5403d80
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -1129,6 +1129,8 @@ The following components of LINK-COMMAND are treated specially:
-all-static do not do any dynamic linking at all
-avoid-versiondo not add a version suffix if possible
+ -bindir BINDIRspecify path to $prefix/bin (needed only when installing
+a Windows DLL)
-dlopen FILE \`-dlpreopen' FILE if it cannot be dlopened at runtime
-dlpreopen FILE link in FILE and add its symbols to lt_preloaded_symbols
-export-dynamic allow symbols from OUTPUT-FILE to be resolved with dlsym(3)
@@ -3659,6 +3661,7 @@ func_mode_link ()
new_inherited_linker_flags=
avoid_version=no
+bindir=
dlfiles=
dlprefiles=
dlself=no
@@ -3751,6 +3754,11 @@ func_mode_link ()
esac
case $prev in
+ bindir)
+ bindir=$arg
+ prev=
+ continue
+ ;;
dlfiles|dlprefiles)
if test $preload = no; then
# Add the symbol object into the linking commands.
@@ -4012,6 +4020,11 @@ func_mode_link ()
continue
;;
+ -bindir)
+ prev=bindir
+ continue
+ ;;
+
-dlopen)
prev=dlfiles
continue
@@ -7706,7 +7719,17 @@ EOF
# place dlname in correct position for cygwin
tdlname=$dlname
case $host,$output,$installed,$module,$dlname in
- *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll) tdlname=../bin/$dlname ;;
+ *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll)
+ # If a -bindir argument was supplied, place the dll there.
+ if test x$bindir != x ;
+ then
+ func_relative_path $install_libdir $bindir
+ tdlname=${func_relative_path_result}$dlname
+ else
+ # Otherwise fall back on heuristic.
+ tdlname=../bin/$dlname
+ fi
+ ;;
esac
$ECHO $output \
# $outputname - a libtool library file
diff --git a/tests/pe-dll-inst-bindir.at b/tests/pe-dll-inst-bindir.at
new file mode 100755
index 000..bd42d68
--- /dev/null
+++ b/tests/pe-dll-inst-bindir.at
@@ -0,0 +1,171 @@
+# pe-dll-inst-bindir.at - Test the -bindir option for installing
+# DLLs on PE format architectures.
+#
+# Copyright (C) 2009 Free Software Foundation, Inc.
+# Written by Dave Korn, 2009
+#
+# This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# GNU Libtool is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Libtool; see the file COPYING. If not, a copy
+# can be downloaded from http://www.gnu.org/licenses/gpl.html,
+# or obtained by writing to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+
+noskip=:
+case $host_os in
+cygwin*|mingw*|cegcc*) ;;
+*) noskip=false ;;
+esac
+
+$noskip {
+
+AT_BANNER([Win32 tests])
+AT_SETUP([win32 compile check])
+
+# Verify compiling works.
+
+AT_DATA([simple.c] ,[[
+int main() { return 0;}
+]])
+
+$noskip {
+$CC $CPPFLAGS $CFLAGS -o simple simple.c 21 /dev/null || noskip=false
+rm -f simple
+}
+
+AT_CHECK([$noskip || (exit 77)])
+
+AT_CLEANUP
+
+# Now the tests themselves.
+
+AT_SETUP([win32 dll basic])
+
+AT_DATA([foo.c],[[
+int x=0;
+]])
+
+AT_DATA([baz.c],[[
+int y=0;
+]])
+
+AT_DATA([bar.c],[[
+extern int x;
+int bar(void);
+int bar() { return x;}
+]])
+
+AT_DATA([main.c
[PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
+ func_relative_path_tcancelled=$func_relative_path_tbindir
+ break
+ fi
+ func_relative_path_result=../$func_relative_path_result
+ ;;
+esac
+ done
+
+ # Now calculate path; take care to avoid doubling-up slashes.
+ func_stripname '' '/' $func_relative_path_result
+ func_relative_path_result=$func_stripname_result
+ func_stripname '' '/' $func_relative_path_tcancelled
+ func_relative_path_result=${func_relative_path_result}${func_stripname_result}
+
+ # Normalisation. If bindir is libdir, return empty string,
+ # if subdir return string beginning './', else relative path
+ # ending with a slash; either way, target file name can be
+ # directly appended.
+ if test -z $func_relative_path_result; then
+func_relative_path_result=./
+ else
+func_stripname './' '' $func_relative_path_result/
+func_relative_path_result=$func_stripname_result
+ fi
+}
+
# The name of this program:
func_dirname_and_basename $progpath
progname=$func_basename_result
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
old mode 100644
new mode 100755
index ebd3909..5403d80
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -1129,6 +1129,8 @@ The following components of LINK-COMMAND are treated specially:
-all-static do not do any dynamic linking at all
-avoid-versiondo not add a version suffix if possible
+ -bindir BINDIRspecify path to $prefix/bin (needed only when installing
+a Windows DLL)
-dlopen FILE \`-dlpreopen' FILE if it cannot be dlopened at runtime
-dlpreopen FILE link in FILE and add its symbols to lt_preloaded_symbols
-export-dynamic allow symbols from OUTPUT-FILE to be resolved with dlsym(3)
@@ -3659,6 +3661,7 @@ func_mode_link ()
new_inherited_linker_flags=
avoid_version=no
+bindir=
dlfiles=
dlprefiles=
dlself=no
@@ -3751,6 +3754,11 @@ func_mode_link ()
esac
case $prev in
+ bindir)
+ bindir=$arg
+ prev=
+ continue
+ ;;
dlfiles|dlprefiles)
if test $preload = no; then
# Add the symbol object into the linking commands.
@@ -4012,6 +4020,11 @@ func_mode_link ()
continue
;;
+ -bindir)
+ prev=bindir
+ continue
+ ;;
+
-dlopen)
prev=dlfiles
continue
@@ -7706,7 +7719,17 @@ EOF
# place dlname in correct position for cygwin
tdlname=$dlname
case $host,$output,$installed,$module,$dlname in
- *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll) tdlname=../bin/$dlname ;;
+ *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll)
+ # If a -bindir argument was supplied, place the dll there.
+ if test x$bindir != x ;
+ then
+ func_relative_path $install_libdir $bindir
+ tdlname=${func_relative_path_result}$dlname
+ else
+ # Otherwise fall back on heuristic.
+ tdlname=../bin/$dlname
+ fi
+ ;;
esac
$ECHO $output \
# $outputname - a libtool library file
diff --git a/tests/pe-dll-inst-bindir.at b/tests/pe-dll-inst-bindir.at
new file mode 100755
index 000..a0f45e5
--- /dev/null
+++ b/tests/pe-dll-inst-bindir.at
@@ -0,0 +1,171 @@
+# pe-dll-inst-bindir.at - Test the -bindir option for installing
+# DLLs on PE format architectures.
+#
+# Copyright (C) 2009 Free Software Foundation, Inc.
+# Written by Dave Korn, 2009
+#
+# This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# GNU Libtool is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Libtool; see the file COPYING. If not, a copy
+# can be downloaded from http://www.gnu.org/licenses/gpl.html,
+# or obtained by writing to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+
+noskip=:
+case $host_os in
+cygwin*|mingw*|cegcc*) ;;
+*) noskip=false ;;
+esac
+
+$noskip {
+
+AT_BANNER([PE DLL install tests])
+AT_SETUP([simple compile check])
+
+# Verify compiling works.
+
+AT_DATA([simple.c] ,[[
+int main() { return 0;}
+]])
+
+$noskip {
+$CC $CPPFLAGS $CFLAGS -o simple simple.c 21 /dev/null || noskip=false
+rm -f simple
+}
+
+AT_CHECK([$noskip || (exit 77)])
+
+AT_CLEANUP
+
+# Now the tests themselves.
+
+AT_SETUP([dll basic test])
+
+AT_DATA([foo.c],[[
+int x=0;
+]])
+
+AT_DATA([baz.c],[[
+int y=0;
+]])
+
+AT_DATA([bar.c],[[
+extern int x;
+int bar(void);
+int bar() { return x;}
+]])
+
+AT_DATA([main.c],[[
+extern int x;
+extern int y;
+
+int main() {
+return x+y;
+}
+]])
+
+AT_CHECK([$LIBTOOL --mode=compile
[PATCH+Assign request][cygwin|mingw] Control where win32 DLLs get installed.
100644
new mode 100755
index ebd3909..5403d80
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -1129,6 +1129,8 @@ The following components of LINK-COMMAND are treated specially:
-all-static do not do any dynamic linking at all
-avoid-versiondo not add a version suffix if possible
+ -bindir BINDIRspecify path to $prefix/bin (needed only when installing
+a Windows DLL)
-dlopen FILE \`-dlpreopen' FILE if it cannot be dlopened at runtime
-dlpreopen FILE link in FILE and add its symbols to lt_preloaded_symbols
-export-dynamic allow symbols from OUTPUT-FILE to be resolved with dlsym(3)
@@ -3659,6 +3661,7 @@ func_mode_link ()
new_inherited_linker_flags=
avoid_version=no
+bindir=
dlfiles=
dlprefiles=
dlself=no
@@ -3751,6 +3754,11 @@ func_mode_link ()
esac
case $prev in
+ bindir)
+ bindir=$arg
+ prev=
+ continue
+ ;;
dlfiles|dlprefiles)
if test $preload = no; then
# Add the symbol object into the linking commands.
@@ -4012,6 +4020,11 @@ func_mode_link ()
continue
;;
+ -bindir)
+ prev=bindir
+ continue
+ ;;
+
-dlopen)
prev=dlfiles
continue
@@ -7706,7 +7719,17 @@ EOF
# place dlname in correct position for cygwin
tdlname=$dlname
case $host,$output,$installed,$module,$dlname in
- *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll) tdlname=../bin/$dlname ;;
+ *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll)
+ # If a -bindir argument was supplied, place the dll there.
+ if test x$bindir != x ;
+ then
+ func_relative_path $install_libdir $bindir
+ tdlname=${func_relative_path_result}$dlname
+ else
+ # Otherwise fall back on heuristic.
+ tdlname=../bin/$dlname
+ fi
+ ;;
esac
$ECHO $output \
# $outputname - a libtool library file
diff --git a/tests/win32.at b/tests/win32.at
new file mode 100755
index 000..1d36add
--- /dev/null
+++ b/tests/win32.at
@@ -0,0 +1,170 @@
+# win32.at - tests specific to Cygwin and MinGW
+#
+# Copyright (C) 2009 Free Software Foundation, Inc.
+# Written by Dave Korn, 2009
+#
+# This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# GNU Libtool is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Libtool; see the file COPYING. If not, a copy
+# can be downloaded from http://www.gnu.org/licenses/gpl.html,
+# or obtained by writing to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+
+noskip=:
+case $host_os in
+cygwin*|mingw*) ;;
+*) noskip=false ;;
+esac
+
+$noskip {
+
+AT_BANNER([Win32 tests])
+AT_SETUP([win32 compile check])
+
+# Verify compiling works.
+
+AT_DATA([simple.c] ,[[
+int main() { return 0;}
+]])
+
+$noskip {
+$CC $CPPFLAGS $CFLAGS -o simple simple.c 21 /dev/null || noskip=false
+rm -f simple
+}
+
+AT_CHECK([$noskip || (exit 77)])
+
+AT_CLEANUP
+
+# Now the tests themselves.
+
+AT_SETUP([win32 dll basic])
+
+AT_DATA([foo.c],[[
+int x=0;
+]])
+
+AT_DATA([baz.c],[[
+int y=0;
+]])
+
+AT_DATA([bar.c],[[
+extern int x;
+int bar(void);
+int bar() { return x;}
+]])
+
+AT_DATA([main.c],[[
+extern int x;
+extern int y;
+
+int main() {
+return x+y;
+}
+]])
+
+AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC -c -o foo.lo $CPPFLAGS $CFLAGS foo.c],[0],[ignore],[ignore])
+
+AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC -c -o baz.lo $CPPFLAGS $CFLAGS baz.c],[0],[ignore],[ignore])
+
+AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC -no-undefined -shared -o libfoo.la $CPPFLAGS $CFLAGS $LDFLAGS foo.lo baz.lo -rpath /nonexistent],[0],[ignore],[ignore])
+
+AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC -c -o bar.lo $CPPFLAGS $CFLAGS bar.c],[0],[ignore],[ignore])
+
+AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC -no-undefined -shared -o libbar.la $CPPFLAGS $CFLAGS $LDFLAGS bar.lo libfoo.la -rpath /nonexistent],[0],[ignore],[ignore])
+
+AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC -c -o main.lo $CPPFLAGS $CFLAGS main.c],[0],[ignore],[ignore])
+
+AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC -o main$EXEEXT $CPPFLAGS $CFLAGS $LDFLAGS main.lo libbar.la],[0],[ignore],[ignore])
+
+AT_CLEANUP
+
+AT_SETUP([win32 dll install to bindir])
+
+AT_DATA([foo.c],[[
+int x=0;
+]])
+
+AT_DATA([bar.c],[[
+extern int x;
+int bar(void);
+int bar() { return x;}
+]])
+
+AT_DATA([baz.c],[[
+int y=0;
+]])
+
+AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC -c -o foo.lo $CPPFLAGS
Re: [PATCH+Assign request][cygwin|mingw] Control where win32 DLLs get installed.
Charles Wilson wrote: [ snip ] Thanks for all the shell portability advice, it's pretty specialised stuff that I don't know all about; I'll incorporate your changes into the respin when I add the docs. I'm not sure -rpath is the right way to test, here. I know you're trying to avoid doing a full configure --prefix= --bindir= test, but I've only rarely seen the -rpath flag used on win32, so I'm not sure this test is exercising the normal usage pattern. Well, I did really want to make it a test of nothing other than the -bindir functionality, in fact it's more or less just a test of the corner cases for func_relative_path! Using -rpath seems to work as far as supplying an input value for $install_libdir and that's all I really want to achieve here: set $install_libdir and $bindir and make sure that chunk of code DTRT. I think it'll be OK, won't it, even if it is a bit unusual? cheers, DaveK
RE: mdemo ltdl failure
On 16 March 2007 15:35, Charles Wilson wrote: Well, it's failing all the time for me, but I'm not sure it's a segfault. What does Hangup mean, when reported by the shell after executing the app: Good question, I don't know. It means SIGHUP. I've (almost) tracked down the error: it is caused by yet another bug in newlib's argz_insert() (or possibly realloc()! ), as called by lt_argz_insert: This thread should probably be on the newlib list then. What's odd is that this bug in argz_insert() is very ticklish: it triggers on tests/mdemo/Makefile, but not when argz_insert is called with ./tests/mdemo/Makefile. Isn't that just exactly what you would expect, given that you're talking about sorting things in ascii order? The period collates very early in ascii sort order, whereas a lower-case t comes much later; hence if you specify the '.' you get the makefile at the start of the list instead of the end. I need to verify this using a debug-built cygwin kernel, but it looks like within newlib's argz_insert(), the call to realloc() is not operating correctly in this instance. Sounds like it should be quite easy to PPAST then. cheers, DaveK -- Can't think of a witty .sigline today
