Re: lapack 3.0 (OpenGL and ncurses maintainers please take note)
On Jun 29 22:40, James R. Phillips wrote: --- Charles Wilson wrote: FWIW, I think the /opt tree is PRECISELY the right thing to do with regards to the un-optimized lapack DLLs. With PATH manipulations, binaries like octave.exe can find the appropriate lapack DLLs -- unoptimized if /opt/lapack/bin is the only dir in PATH containing them; optimized if the local administrator installs optimized versions somewhere (/usr/local/bin?) and takes affirmative steps to ensure that /usr/local/bin precedes /opt/lapack/bin in $PATH. Are there any other official packages that install to /opt? I don't have an /opt at all in my cygwin directory tree. I am reluctant to create a new top-level directory just for part of one package. Not that this couldn't work. What were down to is just a preference. Somewhere in opt would work; so would /usr/lib/lapack. I'd opt for /opt (sorry for the pun). Bigger and more complex packages are better served by getting their own /opt subdir in the long run. Charles is asking for /opt for a while now anyway. Perhaps the lapack package would be a good start. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Second Trial Packaging for lapack 3.0
OK, I changed the installation dir for the unoptimized dll's to /usr/lib/lapack. Updated source and binary packages are located at ftp://antiskid.homelinux.net/pub/lapack I still consider this a trial packaging; I'm not asking for an upload yet. Core maintainers, please advise of any packaging issues. I still can't get passive ftp to work through my nat router, despite attempts tonight to fix the wu-ftp configuration. Please use command line-ftp or i.e. to retrieve these files. Thanks, Jim Phillips
Re: lapack 3.0 (OpenGL and ncurses maintainers please take note)
--- Corinna Vinschen wrote: I'd opt for /opt (sorry for the pun). Bigger and more complex packages are better served by getting their own /opt subdir in the long run. Charles is asking for /opt for a while now anyway. Perhaps the lapack package would be a good start. Please look over the directory structure of the trial binary package at ftp://antiskid.homelinux.net/pub/lapack It doesn't seem all that complex to me, but if it passes the /opt complex threshold for you, please advise how package subtrees would best be reallocated. I.E. should /opt have its own share/doc subtree, etc. Thanks, Jim Phillips
Libtool: erroneous relinking
I'm running into a problem building the apache subversion modules, where libtool builds them fine, but then screws up when it tries to relink them for installation. Now, I thought that relinking was only for altering the linked-in rpath, from the build directory to the final install directory? If so, then since DLLs don't have an rpath, is there any point whatsoever in relinking them? I'd like to know whether the answer is to simply disable relinking entirely, before I dig into the guts of libtool. Thanks. Max.
Re: update-alternatives
Op Wed, 29 Jun 2005 22:32:17 -0400 (EDT) schreef Igor Pechtchanski
in [EMAIL PROTECTED]:
: On Thu, 30 Jun 2005, Bas van Gompel wrote:
[...]
: Op Mon, 27 Jun 2005 00:17:01 -0400 schreef Charles Wilson:
: : Bas van Gompel wrote:
: [Re-adding attribution:]
: + Charles Wilson:
[``wrap'' *not* to wrap DLLs.]
:
: Umm, why not? I mean, the mechanism for wrapping DLLs is very different
: than that of wrapping executables (and much more involved), but isn't
: there a possibility of writing a wrapdll.dll that looks up the name of
: the DLL in the /etc/alternatives database, dlopen's it, and emulates all
: of its functions somehow? ISTR something like this done in my OS class
: ages ago, but don't recall the exact details. Am I misremembering?
I Don't see how this could work. ``Statically'' linked, the wrapper's
``exports''-table would be consulted, would it not?
I can imagine building a custom wrapper-dll for each wrappee, using an
autoload-like method, but don't intend to investigate further, for now.
Wouldn't this kind of thing be easier to address from the context of
``libtool'', in each DLL's build-system?
So far, I can envision this working (reasonably) only when making
gcc/binutils a run-time requirement of ``wrap'', or having a topheavy
(dll-analyzing/building) installer, both of which I'd prefer not to.
[how ``alternatives'' works]
: Yes. I have since seen that ``alternatives'' uses a pure ``C'' approach,
: so my shell-script installers might not be appropriate. It should not be
: hard for ``alternatives'' to copy the wrapper bin-file itself, however.
:
: I wonder if these could be real symlink approximations, i.e., the path
: to the executable to run would sit in some static string at a known
: offset, and the installer could simply write into the executable at that
: offset? Or is this too much?
I guess this could be done... Nice idea. I will look into it.
Thanks.
There is probably a CRC to contend with somewhere.
: : I'm not sure it's worth your time to do so right now. I think the
: : /bin/ash vs. /bin/bash thing will be resolved some other way, and that's
: : the only pressing need for an MSWin-friendly symlink-wrap-thingy from
: : the perspective of update-alternatives.
:
: I did since however write a ``wrap-alternative'' executable, which uses
: execv... Not having to read a file makes it even simpler than the
: ``wrap'' executable. :)
:
: That actually sounds like what I mentioned above...
It isn't, however. The link is read from ${sysconfdir} + /alternatives/ +
basename(argv[0])''
[FHS-issues]
: Preliminary binary package file-list:
:
: /usr/bin/wrap
: /usr/bin/wrap-alternative
: /usr/lib/wrap/wrap.bin
: /usr/lib/wrap/wrap-alternative.bin
[...]
: Any comments?)
:
: Looks good. You could also provide a create-wrap script/program, that
: would have ln -s semantics and create a wrapped executable (and it could
: also check that the thing you're wrapping *is* an executable, and not,
: say, a DLL). That way, if you decide to switch the implementation later,
: the scripts that create wrapped executables won't have to change.
In the above, /usr/bin/wrap and /usr/bin/wrap-alternative are the
scripts you suggest (No checking for DLLs (or non-executables for that
matter) yet, though). I should rename them I guess. It's confusing
already. create-wrap? install-wrap? mkwrap?
: HTH,
It does, thanks.
L8r,
Buzz.
--
) | | ---/ ---/ Yes, this | This message consists of true | I do not
-- | | // really is | and false bits entirely.| mail for
) | | //a 72 by 4 +---+ any1 but
-- \--| /--- /--- .sigfile. | |perl -pe s.u(z)\1.as.| me. 4^re
Re: Libtool: erroneous relinking
Max Bowsher wrote: I'm running into a problem building the apache subversion modules, where libtool builds them fine, but then screws up when it tries to relink them for installation. Now, I thought that relinking was only for altering the linked-in rpath, from the build directory to the final install directory? If so, then since DLLs don't have an rpath, is there any point whatsoever in relinking them? I'd like to know whether the answer is to simply disable relinking entirely, before I dig into the guts of libtool. I do so in locally applied changes, I see no problems. Gerrit -- =^..^=
Re: Libtool: erroneous relinking
Gerrit P. Haase wrote: Max Bowsher wrote: I'm running into a problem building the apache subversion modules, where libtool builds them fine, but then screws up when it tries to relink them for installation. Now, I thought that relinking was only for altering the linked-in rpath, from the build directory to the final install directory? If so, then since DLLs don't have an rpath, is there any point whatsoever in relinking them? I'd like to know whether the answer is to simply disable relinking entirely, before I dig into the guts of libtool. I do so in locally applied changes, I see no problems. Search for need_relink=yes around line 2453 in ltmain.sh and set to no before reconfiguring. Gerrit -- =^..^=
Re: update-alternatives
Bas van Gompel wrote: I Don't see how this could work. ``Statically'' linked, the wrapper's ``exports''-table would be consulted, would it not? I can imagine building a custom wrapper-dll for each wrappee, using an autoload-like method, but don't intend to investigate further, for now. Presumably that's what Igor meant, i.e. making a stub DLL with entry points for every function in the API, and some kind of means of determining which version of the DLL to use, and a call to LoadLibrary() that would pick the correct one and pass though all calls. I don't see how this would be possible in the general sense though. The wrapper DLL would have to know all the exports at compile time. If the application could hook into calls to GetProcAddress(), then it could essentially proxy a DLL. The wrapper DLL could choose from one or more alternative target DLLs, call LoadLibrary() on that DLL, and then pass-through the GetProcAddress calls. But this would only work for run-time dynamic libraries, I see no chance of this being able to proxy a DLL that a binary was linked against. I'm sure that's possible too but it would take some mondo knowledge of win32 API internals. On a related note... there is a Microsoft Way(tm) of doing this, with side-by-side assemblies and manifests: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/side_by_side_assemblies.asp. In theory you could attach a manifest to the .exe that would tell the loader exactly which DLLs to use, instead of having to do it though PATH manipulation. And a manifest need not be internal to the .exe, it can be a seperate file, so I guess there is the potential for using this in the scenario mentioned above. But it's an XP-and-later feature anyway, so not of much use to the project in general. Brian
Please Upload: epstool-3.08-1
In response to recent upstream release, please upload ftp://antiskid.homelinux.net/pub/epstool/epstool-3.08-1.tar.bz2 ftp://antiskid.homelinux.net/pub/epstool/epstool-3.08-1-src.tar.bz2 Due to upstream interest in cygwin builds, this release builds OOTB, and thus there is no patch file in the src package. No updates to setup.hint. Please avoid ftp clients that use the PASV command, as my ftp server configuration is not compatible with that at this time. I.E. seems to work, as does command-line ftp. Thanks Jim Phillips
ITP: octave-2.1.71
cygwin maintainers, With some strong assistance from octave upstream (John W. Eaton at octave.org) in tailoring the g-b-s for octave, I am close to having an octave package for upload. It is linked against lapack (see my ITP for lapack), so lapack is a build dependency. Upstream has provided two binary packages from a single source package: the main octave package, and an accompanying octave-headers package, which is required for compiling new octave binary (.oct) functions. The proposed setup.hint files are as follows: FOR OCTAVE sdesc: The GNU Octave language for numerical computations category: Math requires: cygwin lapack gnuplot less readline texinfo ldesc: The GNU Octave language for numerical computations Octave is a (mostly Matlab (R) compatible) high-level language, primarily intended for numerical computations. It provides a convenient command-line interface for solving linear and nonlinear problems numerically. FOR OCTAVE-HEADERS sdesc: Header files for the GNU Octave language category: Math requires: cygwin octave gcc g++ g77 libncurses-devel external-source: octave ldesc: Header files for the GNU Octave language. This packages provides the include files needed to compile and link user-supplied code with GNU Octave. If you only write interpreted .m files, you do not need this package. --- Please provide comments on the proposal. Thanks, Jim Phillips
Re: ITP: octave-2.1.71
James R. Phillips wrote: With some strong assistance from octave upstream (John W. Eaton at octave.org) in tailoring the g-b-s for octave, I am close to having an octave package for upload. It is linked against lapack (see my ITP for lapack), so lapack is a build dependency. Upstream has provided two binary packages from a single source package: the main octave package, and an accompanying octave-headers package, which is required for compiling new octave binary (.oct) functions. Out of curiosity, what if anything have you done to address the SJLJ issue/PR 14563? To summarize, the Cygwin packaged gcc has had --enable-sjlj-exceptions for quite a while because DW2 exceptions are broken in certain circumstances (namely, when throwing an exception in a function used in a callback where the caller doesn't know DW2, eg. win32 api.) I don't know much at all about octave but if it does not use any callbacks in these situations then it might be worthwhile if you compiled the binaries with a DW2 EH-enabled gcc, to avoid the massive speed hit reported. Brian
Re: ITP: octave-2.1.71
--- Brian Dessent wrote: Out of curiosity, what if anything have you done to address the SJLJ issue/PR 14563? To summarize, the Cygwin packaged gcc has had --enable-sjlj-exceptions for quite a while because DW2 exceptions are broken in certain circumstances (namely, when throwing an exception in a function used in a callback where the caller doesn't know DW2, eg. win32 api.) I don't know much at all about octave but if it does not use any callbacks in these situations then it might be worthwhile if you compiled the binaries with a DW2 EH-enabled gcc, to avoid the massive speed hit reported. Brian Brian, This issue occurs in John Eaton's list of stuff to do, but I don't know anything else about it. Will forward to octave maintainers list for comments. Thanks. Jim Phillips
