RE: Setup vertical scrollbar doesn't display
> --- Richard Garrison <[EMAIL PROTECTED]> wrote: > >The vertical scrollbar in the setup (initiated from > >the download now icon) doesn't display in my windows > >XP pro (service pack 1 - mobile PIII) box. Using the > >identical procedure on my windows 2k boxes works fine > >(the scrollbar displays). > > > >I didn't find anything about this on the web, the > >mailing list archives, or the FAQ (sorry in advance if > >i was blind). > > It has been discussed before. Maybe you searched the wrong list, or used the lists' built-in search. Don't bother with the latter; use Google, it'll find hits in the archive. > >Tried changing the desktop theme to see if it was > >somehow related...it wasn't. > > There are a number of issues with the chooser window's scroll bar. Well, two that I can recall: sporadic scrolly-wheel ignoring, and even more sporadic not-showing-up-at-all. Both are machine-related somehow; e.g. on my XP machine at home, the scrolly wheel always works, on my XP machine at work it always doesn't. I haven't looked into it yet, but I suspect there's something going on with the parent/owner relationships or some such Windows arcanery. It's on the list. This too will pass... eventually. -- Gary R. Van Sickle Brewer. Patriot.
RE: Integrating Ralf's rebase into setup.exe
How about "libhabackersimagehelp.a" etc? -- Gary R. Van Sickle Brewer. Patriot. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Ralf Habacker > Sent: Thursday, January 02, 2003 3:50 AM > To: Robert Collins > Cc: Jason Tishler; [EMAIL PROTECTED] > Subject: RE: Integrating Ralf's rebase into setup.exe > > > > > If I remember right, this lib will be used for a cygwin based > > rebase and later > > > in the cygwin's setup application which is mingw based. So this > lib must be > > > buildable for cygwin and mingw, isn't it ? > > > > Yes. And the library should use the appropriate naming convention for > > the target platform. > > I *don't* think it should be named libimagehlp.a, > > because it's *not* a 100% replacement for libimagehlp. > > You have already stated > > - libcygimagehlp (for cygwin applications like rebase) > > Do you mean > > - libmingwimagehlp > > for setup.exe ? > > What about the header ? It could be the same in both variants. > Symbolic linking > ? > > cygimagehlp.h > mingwimagehlp.h -> cygimagehlp.h > > I think that's bad. The bfd library is named libbfd.xx on every platform, so > this library should be named in another way. > > What about imagehelper.a and imagehelper.h and using autoconf stuff ? > > Ralf >
Re: Setup vertical scrollbar doesn't display
Redirecting to the correct mailing-list. Elfyn [EMAIL PROTECTED] --- Richard Garrison <[EMAIL PROTECTED]> wrote: >The vertical scrollbar in the setup (initiated from >the download now icon) doesn't display in my windows >XP pro (service pack 1 - mobile PIII) box. Using the >identical procedure on my windows 2k boxes works fine >(the scrollbar displays). > >I didn't find anything about this on the web, the >mailing list archives, or the FAQ (sorry in advance if >i was blind). > >Tried changing the desktop theme to see if it was >somehow related...it wasn't. > >All i want to do is install some packages (XFree) >beyond the scope of the window. I can't seem to find a >way to fool the installer. (i tried dowloading >everything i needed onto the win2k box (where the >scrollbar displayed)...and then copying it all to the >xp box, hoping that the install preferences would >followthey didn't) > >Any help would behelpful? > > > >__ >Do you Yahoo!? >Yahoo! Mail Plus - Powerful. Affordable. Sign up now. >http://mailplus.yahoo.com > >-- >Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple >Bug reporting: http://cygwin.com/bugs.html >Documentation: http://cygwin.com/docs.html >FAQ: http://cygwin.com/faq/ _ www.smokeJet.com - Free UK Internet Services _ Select your own custom email address for FREE! Get [EMAIL PROTECTED] w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag
Re: Integrating Ralf's rebase into setup.exe
Ralf Habacker wrote:
You have gotten me just between finishing the things. I was interrupted a little
after written the last mail, so 10 minutes later is was mostly fixed.
Lucky me.
5) is the 'bindimage.cc' file used at all?
it is used in rebind_main.cc.
You mean it *should* be used in rebind_main.cc. It's not listed in
Makefile.in as one of the dependencies for REBIND_FILES, nor is it a
member of LIBFILES.
Of course, rebind_main doesn't call BindImage or BindImageEx. It does
have a commented-out call to dll.rebind() -- but
LinkedObjectFile::rebind() doesn't call BindImage() or BindImageEx
either -- LinkedObjectFile::rebind() does all of the work itself.
Looks like the factorization isn't quite complete...work in progress, right?
Anyway, here's my remaining patches. With two exceptions (Makefile and
rebase_main.cc (main)), these are basically removing all printf calls
and stdio.h, in favor of cout, cerr, and stream manipulators.
Anything that was printf() became std::cout, fprintf(stderr,) became
cerr. However, there are still some "design" issues that I didn't touch:
1) some that go to stdout probably should be stderr, and vice versa.
2) some are guarded by 'if (debug)' and probably should be 'if (some
library call that returns the value of debug for this instance)' -- but
I didn't really check the lexical scope. These may be fine.
3) some aren't even guarded at all, and should be.
4) Then there's that whole exceptions vs. print-an-error-message from
within the library deal.
The point is, ALL console output is now C++, cout/cerr style (before, it
was half C++, half printf)
--Chuck
2002-01-02 Charles Wilson <[EMAIL PROTECTED]>
* Makefile.in: add bindimage.o to LIBFILES
change ar flags for creating static library
* bindimage.cc: include imagehelper.h
* objectfile.cc: remove dependency on stdio.h, use
iostream and iomanip instead.
(ObjectFile::ObjectFile): use std::cout instead of
printf, std::cerr instead of fprintf(stderr,...)
(LinkedObjectFile::rebind): ditto.
(LinkedObjectFile:LinkedObjectFile): ditto.
(LinkedObjectFile::PrintDependencie): ditto.
(LinkedObjectFile::unbind): ditto.
(main): ditto.
* objectfilelist.cc: remove dependency on stdio.h, use
iostream instead.
(main): use std::cout instead of
printf, std::cerr instead of fprintf(stderr,...)
* rebase_main.cc: remove dependency on stdio.h
(main): don't call GetLastError() twice, use stored
value in aStatus2. Call strerror() for a more informative
message.
* rebind_main.cc: remove dependency on stdio.h
(Usage): use std::cout instead of printf, std::cerr
instead of fprintf(stderr,...)
* sections.cc: remove dependency on stdio.h, use
iostream and iomanip instead.
(Section::print): use std::cout instead of printf, std::cerr
instead of fprintf(stderr,...)
(Exports::Exports): ditto.
(Exports::dump): ditto.
(Imports::Imports): ditto.
(Imports::dump): ditto.
(Relocations::check): ditto.
(Relocations::fix): ditto.
(Relocations::relocate): ditto.
* unbind_main (Usage): ditto.
Index: Makefile.in
===
RCS file: /cvsroot/kde-cygwin/tools/rebase/Makefile.in,v
retrieving revision 1.1
diff -u -r1.1 Makefile.in
--- Makefile.in 2 Jan 2003 18:14:32 - 1.1
+++ Makefile.in 2 Jan 2003 18:35:56 -
@@ -9,7 +9,8 @@
LIB_TARGET=imagehelper
LIB_TARGET_FILE=libimagehelper.a
LIB_FILES=objectfile.o objectfilelist.o sections.o debug.o \
- rebaseimage.o checkimage.o fiximage.o
getimageinfos.o
+ rebaseimage.o checkimage.o fiximage.o
+getimageinfos.o \
+ bindimage.o
#
# applications
@@ -33,7 +34,7 @@
$(LIB_TARGET): $(LIB_TARGET_FILE)
$(LIB_TARGET_FILE): $(LIB_FILES)
- ar -qf $@ $^
+ ar -cru $@ $^
$(REBASE_TARGET): $(REBASE_FILES)
$(CXX) $(CXXFLAGS) -o $@ $^ $(LDFLAGS)
Index: bindimage.cc
===
RCS file: /cvsroot/kde-cygwin/tools/rebase/bindimage.cc,v
retrieving revision 1.5
diff -u -r1.5 bindimage.cc
--- bindimage.cc1 Jan 2003 11:55:49 - 1.5
+++ bindimage.cc2 Jan 2003 18:35:57 -
@@ -21,6 +21,7 @@
#include
#include
+#include "imagehelper.h"
#include "objectfile.h"
BOOL BindImageEx(
Index: objectfile.cc
===
RCS file: /cvsroot/kde-cygwin/tools/rebase/objectfile.cc,v
retrieving revision 1.6
diff -u -r1.6 objectfile.cc
--- objectfile.cc 2 Jan 2003 17:05:14 - 1.6
+++ objectfile.cc 2 Jan 2003 18:35:59 -
@@ -18,8 +18,9 @@
* $Id: objectfile.cc,v 1.6 2003/01/02 17:05:14 habacker Exp $
*/
-#include
#include
+#include
+#include
#include
#include "objectfile.h"
@@ -78,7 +79,7 @@
strcat(name,"/");
strcat(name,basename);
if (debug)
-printf("%s: name: %
RE: Integrating Ralf's rebase into setup.exe
> Not really -- it doesn't compile anymore. Among other things: You have gotten me just between finishing the things. I was interrupted a little after written the last mail, so 10 minutes later is was mostly fixed. > 0) Update the changelog when you do stuff. (You renamed the library > itself, and that doesn't rate a mention in the ChangeLog?) > fixed > 1) you need to 'cvs add imagehelper.h' > (and 'rm imagehlp.h && cvs remove imagehlp.h') > This is the biggie -- all of the .cc files now look for > imagehelper.h -- but it isn't in CVS. > fixed > 2) you probably should also > rm imagehlpdebug.cc && cvs remove imagehlpdebug.cc > since you're actually using the nearly identical 'debug.cc' file > instead. > fixed > 3) Makefile rule for REBASE_FILES should be changed back to > REBASE_FILES=rebase_main.o version.o $(LIB_TARGET_FILE) > fixed > 4) You probably should use "ar cru" to create your static library, "ar > qf" will flake unless you ranlib it each time. > > 5) is the 'bindimage.cc' file used at all? > it is used in rebind_main.cc. Ralf
Re: Integrating Ralf's rebase into setup.exe
Ralf Habacker wrote: Thats orthogonal (but IIRC is possible now/soon). The build within setup.exe will be a .a library, not a .dll. You could always use a compile flag to choose between cout error reporting and exceptions. What about the following: Step 1: library for standalone rebase Step 1 is already in already supported. Not really -- it doesn't compile anymore. Among other things: 0) Update the changelog when you do stuff. (You renamed the library itself, and that doesn't rate a mention in the ChangeLog?) 1) you need to 'cvs add imagehelper.h' (and 'rm imagehlp.h && cvs remove imagehlp.h') This is the biggie -- all of the .cc files now look for imagehelper.h -- but it isn't in CVS. 2) you probably should also rm imagehlpdebug.cc && cvs remove imagehlpdebug.cc since you're actually using the nearly identical 'debug.cc' file instead. 3) Makefile rule for REBASE_FILES should be changed back to REBASE_FILES=rebase_main.o version.o $(LIB_TARGET_FILE) 4) You probably should use "ar cru" to create your static library, "ar qf" will flake unless you ranlib it each time. 5) is the 'bindimage.cc' file used at all? 6) I've got more, but they depend on the above things, which aren't really patches... --Chuck
RE: Integrating Ralf's rebase into setup.exe
> IIRC, it is not part of Mingw. > > I just used a copy of getopt.[ch] from the Cygwin sources for my stand > alone rebase. > That curious: getopt is compiled into /usr/lib/mingw/libliberty.a; only the header is missing. I've copied the header from /usr/include/getopt.h to /usr/include/mingw and it works. Now it seme to works. I have checked in the recent version in the cvs. Ralf
Re: Integrating Ralf's rebase into setup.exe
Ralf, On Thu, Jan 02, 2003 at 05:00:52PM +0100, Ralf Habacker wrote: > What about getopt, ... IIRC, it is not part of Mingw. I just used a copy of getopt.[ch] from the Cygwin sources for my stand alone rebase. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
RE: Integrating Ralf's rebase into setup.exe
> But, they are part of Cygwin gcc in Mingw mode (i.e., gcc -mno-cygwin). > You're right. My gcc installation was corrupted. Now I can compile it. What about getopt, I can find the symbol in a library, but not the related header. ? I have installed mingw-runtime 2.2.1. Ralf
Re: Integrating Ralf's rebase into setup.exe
On Thu, Jan 02, 2003 at 04:23:08PM +0100, Ralf Habacker wrote: >> My stand alone rebase is currently a Mingw app. However, it was >> initially a Cygwin app but I switched in over to Mingw when Chuck >> pointed out that imagehlp.dll is dependent on msvcrt.dll. >> >> Now that I will be using your rebase functionality instead, I have the >> option to switch back to Cygwin. For various reasons, I was intending >> on keeping my stand alone rebase a Mingw app. What do others think? >> >Hm, what about mingw and the stdlib++ library ? This library seems not to be >part of the regular mingw package. libstdc++.a is part of the gcc-mingw package. cgf
Re: Integrating Ralf's rebase into setup.exe
Ralf, On Thu, Jan 02, 2003 at 04:23:08PM +0100, Ralf Habacker wrote: > > Now that I will be using your rebase functionality instead, I have > > the option to switch back to Cygwin. For various reasons, I was > > intending on keeping my stand alone rebase a Mingw app. What do > > others think? > > > Hm, what about mingw and the stdlib++ library ? This library seems not > to be part of the regular mingw package. But, they are part of Cygwin gcc in Mingw mode (i.e., gcc -mno-cygwin). Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
RE: Integrating Ralf's rebase into setup.exe
> My stand alone rebase is currently a Mingw app. However, it was > initially a Cygwin app but I switched in over to Mingw when Chuck > pointed out that imagehlp.dll is dependent on msvcrt.dll. > > Now that I will be using your rebase functionality instead, I have the > option to switch back to Cygwin. For various reasons, I was intending > on keeping my stand alone rebase a Mingw app. What do others think? > Hm, what about mingw and the stdlib++ library ? This library seems not to be part of the regular mingw package. Ralf
Re: Integrating Ralf's rebase into setup.exe
Ralf, On Thu, Jan 02, 2003 at 10:27:12AM +0100, Ralf Habacker wrote: > If I remember right, this lib will be used for a cygwin based rebase > and later in the cygwin's setup application which is mingw based. So > this lib must be buildable for cygwin and mingw, isn't it ? My stand alone rebase is currently a Mingw app. However, it was initially a Cygwin app but I switched in over to Mingw when Chuck pointed out that imagehlp.dll is dependent on msvcrt.dll. Now that I will be using your rebase functionality instead, I have the option to switch back to Cygwin. For various reasons, I was intending on keeping my stand alone rebase a Mingw app. What do others think? Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
RE: Integrating Ralf's rebase into setup.exe
On Thu, 2003-01-02 at 20:50, Ralf Habacker wrote: > You have already stated > > - libcygimagehlp (for cygwin applications like rebase) > > Do you mean > > - libmingwimagehlp > > for setup.exe ? I really don't care, as long as it doesn't comflict with the real imagehlp library. > What about the header ? It could be the same in both variants. Symbolic linking > ? Likewise. Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- signature.asc Description: This is a digitally signed message part
RE: Integrating Ralf's rebase into setup.exe
> > If I remember right, this lib will be used for a cygwin based > rebase and later > > in the cygwin's setup application which is mingw based. So this lib must be > > buildable for cygwin and mingw, isn't it ? > > Yes. And the library should use the appropriate naming convention for > the target platform. > I *don't* think it should be named libimagehlp.a, > because it's *not* a 100% replacement for libimagehlp. You have already stated - libcygimagehlp (for cygwin applications like rebase) Do you mean - libmingwimagehlp for setup.exe ? What about the header ? It could be the same in both variants. Symbolic linking ? cygimagehlp.h mingwimagehlp.h -> cygimagehlp.h I think that's bad. The bfd library is named libbfd.xx on every platform, so this library should be named in another way. What about imagehelper.a and imagehelper.h and using autoconf stuff ? Ralf
RE: Integrating Ralf's rebase into setup.exe
On Thu, 2003-01-02 at 20:31, Ralf Habacker wrote: > > Thats orthogonal (but IIRC is possible now/soon). The build within > > setup.exe will be a .a library, not a .dll. You could always use a > > compile flag to choose between cout error reporting and exceptions. > > > What about the following: > > Step 1: library for standalone rebase > > Every exported library function sets an error with SetLastError() and returns a > false condition, so a user could inspect this with GetLastError(). > If the library must be debugged set SetImageHlpDebug(1) to enable debug message > printing. Sure. Reporting errors via SetLastError() is fine, its just saw the cout << stuff in the patch, thus my comment. Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- signature.asc Description: This is a digitally signed message part
RE: Integrating Ralf's rebase into setup.exe
On Thu, 2003-01-02 at 20:27, Ralf Habacker wrote: > > Rob suggested libcygimagehlp.a for the library. > > > > Should we leave the names as is, but use -L and -I to find the right > > files instead? > > > If I remember right, this lib will be used for a cygwin based rebase and later > in the cygwin's setup application which is mingw based. So this lib must be > buildable for cygwin and mingw, isn't it ? Yes. And the library should use the appropriate naming convention for the target platform. I *don't* think it should be named libimagehlp.a, because it's *not* a 100% replacement for libimagehlp. Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- signature.asc Description: This is a digitally signed message part
RE: Integrating Ralf's rebase into setup.exe
> Thats orthogonal (but IIRC is possible now/soon). The build within > setup.exe will be a .a library, not a .dll. You could always use a > compile flag to choose between cout error reporting and exceptions. > What about the following: Step 1: library for standalone rebase Every exported library function sets an error with SetLastError() and returns a false condition, so a user could inspect this with GetLastError(). If the library must be debugged set SetImageHlpDebug(1) to enable debug message printing. Step 2: library in setup.exe add exception handling enabled by a -D option. Step 1 is already in already supported. Ralf
RE: Integrating Ralf's rebase into setup.exe
> Rob suggested libcygimagehlp.a for the library. > > Should we leave the names as is, but use -L and -I to find the right > files instead? > If I remember right, this lib will be used for a cygwin based rebase and later in the cygwin's setup application which is mingw based. So this lib must be buildable for cygwin and mingw, isn't it ? Additional I assume a standalone mingw based rebase would be also nice for the mingw people. Any comments ? Ralf
RE: Integrating Ralf's rebase into setup.exe
> Still missing a lot of the errors that were fixed in my patch. Here's > the remainder: > > 1) 'hex' and 'endl' are also in the std:: namespace > 2) unbind_main.cc needs 'using namespace std;' > 3) (new) rebind_main will rebind the first commandline argument over and > over; it needs to use argv[i] not argv[1] > 4) fiximage.cc and rebaseimage.cc seem not have gotten any of the std:: > fixes. > > errmmm...why not inspect the patch below for correctness, and then apply > & commit, rather than implementing all of the fixes by hand, which > invariably will skip/miss some? > Chuck, thanks for this patch. I have applied it. Regards Ralf
