Hi Robert,
you may wondering about you haven't heard anything in the last months after I
have offered some time working on the command line cygwin installer (for
example http://sources.redhat.com/ml/cygwin-apps/2003-11/msg0.html)
but there were some personal (at that time one of my sons
On Friday 12 March 2004 15:51, Egor Duda wrote:
Joe Buehler wrote:
The emacs recompile fails because there is a section in
the initially built emacs.exe named .rdata that the
unexec() code for Cygwin is not expecting. The section
appears to have something to do with exception handling
Corinna Vinschen wrote:
Ok, I don't know how that's implemented in cygipc so I think it might
be necessary to mention that:
The implementation of the MSG, SEM and SHM functions in Cygwin are so
that if the functions are not available (be it that CYGWIN doesn't
contain the word server or
Rob,
2. There are several ways to build the api of such a engine, smaller
approachs (using mostly available code and classes) or bigger approach
(complete rewrite), so at first I would prefer to use the
current code base and to apply minimal changes (see below) to enable gui
and command
Hi
On Fri, 2003-10-31 at 23:33, Frank Richter wrote:
This patch now properly deals with minimizing the window - before, some
sizes/positions were slightly off when the window was minimized and
restored. It also constraints the size of the property sheet, it now
can't get smaller than
On Sat, 2003-11-01 at 12:16, Ralf Habacker wrote:
Rob
I need more time to think about what you have written and how to
start with which class,
I have take some time to inspect how it could be go and have build a
testcase to see what kind of api is needed. Please note that I am
Rob
On Sat, 2003-10-25 at 22:23, Ralf Habacker wrote:
This is in the wrong place: LocalDirSetting::load is the
right method to
query the option from.
While thinking about this a while more, I recognized that there
is some more
basic work necessary how to design the command
On Mon, 2003-10-27 at 03:49, Ralf Habacker wrote:
Hi Rob,
Oh, and please resubmit the patch with the correction I requested..
Rob
here is it. I hope it is correct now.
Not quite: I'm not in the business of splitting up patches and adjusting
changelogs - could you please
Rob,
On Sat, 2003-10-25 at 22:23, Ralf Habacker wrote:
This is in the wrong place: LocalDirSetting::load is the
right method to
query the option from.
While thinking about this a while more, I recognized that there
is some more
basic work necessary how to design the command line
?
2003-02-27 Ralf Habacker [EMAIL PROTECTED]
* libtool.m4 (AC_LIBTOOL_SYS_DYNAMIC_LINKER): Removed
postinstall_cmds and postuninstall_cmds,
added shared library to 'library_names_spec'.
(AC_LIBTOOL_LANG_CXX_CONFIG): Removed import library
generation from
I found another bug (most likely introduce by me in a previous patch)
when rebasing up and the DLL is already based at the requested address.
The attached patch is one way to correct this problem.
Applied and checked in.
Ralf
Just out of curiosity, why has this discussion suddenly moved to cygwin
at cygwin dot com from cygwin-apps at cygwin dot com?
It was my error, an little accident. Sorry
Ralf
Your guard:
(char *)relocp (char *)relocs + size
wasn't tight enough.
My version:
(char *)relocp-SizeOfBlock (char *)relocs + size
seems to be.
What was the problem with this guard: Does it not fix the last entry of a
relocation block ?
Ralf
I can reproduce it now. I will debug and try to fix it myself. If I'm
unsuccessful, then I will ask Ralf for help.
Jason, your rebase depends on the ms imagehelp library, isn't it.
A way may be to try my version with the -D flag. This give some additional hint
about the internals of the dll.
The attached fixes the following:
1. merge problem when you applied (by hand?) the following patch:
http://cygwin.com/ml/cygwin/2002-12/msg00138.html
2. bug I introduced in the above patch when I attempted but did
not successfully fix rebasing up
#1 causes the
recognized that using the same dll
more than one time occurs often because of the automatic dependency tracking.
2003-01-25 Ralf Habacker [EMAIL PROTECTED]
* deffile.h (def_get_module): new prototype.
* deffilep.y (def_get_module): new function.
* pe-dll.c (pe_implied_import_dll
Especially in libtool environments I have recognized that using the
same dll more than one time occurs often because of the automatic
dependency tracking.
I should add, that this problem only occurs when using the dll like an object
file not as a library.
gcc -o xx.exe objectfiles dll.dll
Hi Jason,
The attached patch enables libimagehelper.a to be usable by C source
too.
Applied. Thanks for fixing this.
Ralf
Hi Gary,
How about libhabackersimagehelp.a etc?
this would suggest, that this is my lib, but there are also others who have
worked and probably will work on this library. I habe only started this lib
I think imagehelper will be good.
Ralf
1) some that go to stdout probably should be stderr, and vice versa.
still open. I think debug message should go to cerr and normal printing should
go to cout.
This seems mostly to be fixed in the recent cvs release.
Ralf
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]
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
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
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.
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
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
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,
In checkimage.cc:
- ctFile dll(filename);
+ LinkedObjectFile dll(filename);
fixed.
README needs a brief note about this 0.6 version.
More than I have written in my last email ?
No, it's just that the README file itself contains some brief
descriptions of version 0.1 -- 0.5, but
And heres a show stopper. The library should not use cout at all. It
should throw an exception, and let the user interface handle it.
Does this work also, if this library is compiled as a dll ?
Do you have an example, how to do for this ?
Ralf
Hi all,
relating to the this thread, which starts at
http://www.cygwin.com/ml/cygwin-apps/2002-12/msg00021.html I have updated the
rebase source with :
- creates a static lib containing all needed objectfiles for RebaseImage() and
friends.
The library is named libimagehlp.a and the relating
However, should we use the names libimagehlp.a and imagehlp.h? They
clash with the mingw versions.
Do you have a better name ?
Ralf
I needed to make the following changes before this would compile.
Mostly namespace errors,
the std:: below or something else ?
but also a typo
where ?
and main() void vs. int.
fixed
I figured the library files should explicitly call std::cout friends,
fixed
but the executables
What I am doing wrong ? Should I update my Cygwin version too ?
See the config.log if there is an 'could not find -luser32' or so.
I've encountered missing w32api library search path in recent mingw ld.
perhaps it help to configure with ( I don't remember exactly which VAR I have
used)
Do you have a reason to avoid a patch like this ?
Then again - you do not define D_WIN32 only for qtools subdir, but also
for the src subdir. This means that anycode in the main doxygen
body which
has #ifdef _WIN32 clause in it will choose to use the wrong branch.
Or if you really
tmake is a generator of the Makefile.
It search *.c and *.h files, and generates Makefile.
It cannot generate a perfect Makefile but use it as template.
tmake is very useful with qt, because It's trolltech's software, Qt
library package includes tmake.
HP:
Hi all,
Nicholas Wourms has encountered a segfault on linking qt3, while ld creates the
import library.
Currently I'm investigating some time to fix this and the first results are the
following:
ld uses the function pe_dll_generate_implib (def, impfilename) in pe-dll.c to
create the import
On Mon, Jul 15, 2002 at 02:07:44PM +0200, Ralf Habacker wrote:
using release number like 2.2.2-[ab][0-9] has historical reasons and
because of the problems of the sourceforge file release system as I
wrote in http://www.cygwin.com/ml/cygwin-apps/2002-07/msg00440.html I
can't change
On Sun, Jul 14, 2002 at 09:57:07PM +0200, Ralf Habacker wrote:
Ralf Habacker wrote:
By hand, because sourceforge does not allow any subdirs in the download
area, so upset and other scripts are not usable:-(
upset doesn't rely on subdirs.
Isn't upset used for generating setup.ini from
The package release field must be pure numeric. I.e. 2.2.2-1, not 2.2.2-b1.
If you want a beta tag on packages then try 2.2.2b-1. The package release
field provides no information about package status, just versioning. Use the
package version field to provide such information.
using release
Who is creating kde's setup.ini? Are they writing it by hand,
By hand, because sourceforge does not allow any subdirs in the download area, so
upset and other scripts are not usable:-(
If the former, then the human who wrote it is WRONG. the package name
for the file 'kde-x-1.3.tar.bz2' is
Ralf Habacker wrote:
Who is creating kde's setup.ini? Are they writing it by hand,
By hand, because sourceforge does not allow any subdirs in the
download area, so
upset and other scripts are not usable:-(
Why don't you ASK them to allow you to create folders.
Explain why you need
AFAICT http://prdownloads.sf.net/kde-cygwin/setup.ini is not a valid
setup.ini.
Rob, where is the problem with it. I have updated it after your last hints. Does
I have forgotten something ?
Ralf
[Per instructions at http://kde-cygwin.sourceforge.net/kde2.php]
On Thu, Jun 27, 2002 at 08:02:47PM +1000, Robert Collins wrote:
AFAICT http://prdownloads.sf.net/kde-cygwin/setup.ini is not a valid
setup.ini.
It's a redirect page of some sort.
Yes. They've been screwed by the
On Thu, May 23, 2002 at 11:50:20PM +0200, Ralf Habacker wrote:
If have tested this patch with my cygin /bin dir (345 files) and rebinded kde
2.2.2 dll's and exes (335 files) and have got no problems with
printing import
tables.
2002-05-23 Ralf Habacker [EMAIL PROTECTED
When info-pei386_auto_import = -1 (default) then we continue to issue a
message when auto-importing a variable. If info-pei386_auto_import =
1, then we suppress those informational messages -- the user obviously
knows that she is auto-importing variables, since she explicitly
--enabled
On 27 May 2002
at 17:09, Ralf Habacker wrote:
You
might want to take a look at the actual cvs data for setup.exe. Also,
take a look at the original post which cgf was replying to
(http://www.cygwin.com/ml/cygwin-apps/2002-05/msg00230.html).
Done
I
would also
Hi Ralf,
Here is the patch. It is based on the objdump_ai_segfault_2.patch,
which I have send in before.
See note below
Changelog entry for bfd dir --
2002-05-22 Ralf Habacker [EMAIL PROTECTED]
* peXXigen.c (pe_print_idata()): removed double printed
Regardless, basic patch management would dictate that you provide
patches against plain CVS. You shouldn't expect maintainers to apply
unrelated patches in order to check your changes in.
... but the segfault patch is pending and the removing duplicate line patch
makes no sense (in true it
Nope. Looks good, please submit with a Changelog.
Thanks
Rob
snip
2002-05-26 Ralf Habacker [EMAIL PROTECTED]
* archive_tar.cc (archive_tar::next_file_name()) fixed broken
GNU long name extension support.
Isn't this a Changelog entry ?
Ralf
It doesn't. It can optionally, and with a bit of tweaking, be built
against cygwin1.dll. In the future this willg et easier. The
downloadable setup.exe will always be a mingw application.
... but by default it seems to link to the cygwin dll, how do I avoid this ?
Ralf
Ralf Habacker
-Original Message-
From: [EMAIL PROTECTED]
Hi Ralf, Hi Robert,
Oops. I missed that. If you made (1) look like the following, I have no
obbjection to (2) going:
vma: Hint/Ord Member-Name Bound-To
181798844 _7QString$null 5ff556b8 (1)
I
It doesn't. It can optionally, and with a bit of tweaking,
be built against cygwin1.dll. In the future this willg et easier.
The downloadable setup.exe will always be a mingw application.
... but by default it seems to link to the cygwin dll, how do I
avoid this ? Use Rob's
state.have_longname is set, but never
reset, which inhibits propper generating of following filenames in the archive.
2002-05-26 Ralf Habacker [EMAIL PROTECTED]
* archive_tar.cc (archive_tar::next_file_name()) fixed broken
GNU long name extension support.
Index: archive_tar.cc
Nope. You'll need to debug it. I tested this after Nicholas's recent
remondier and it worked for me.
I have tried and recognized, that there are problems with the GNU long name
extension in archive_tar.cc. The filenames which fails are always over 100
characters long and this is the limit.
From: Don Thorp [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 22, 2002 8:53 PM
To: [EMAIL PROTECTED]
Subject: Problem with cygwin install.
I'm excited to try the software out, but while I was installing it I
received several warnings. I've attached to images for your review.
Do you
vma: Hint/Ord Member-Name
181798844 _7QString$null 5ff556b8
The Import Address Table (difference found)
vma: Hint/Ord Member-Name
5ff556b8 844 _7QString$null
Regards
Ralf Habacker
) and rebinded kde
2.2.2 dll's and exes (335 files) and have got no problems with printing import
tables.
2002-05-23 Ralf Habacker [EMAIL PROTECTED]
* peXXigen.c (pe_print_idata): fixed some seg faults
on printing import tables with auto-imported symbols.
Regards
Ralf
3) Ralf's patch for objdump/cygwin crashes on auto-imported libs
Nick Clifton has applied a patch for a similar problem, I will look if this
solve this already.
This patch does not help in this case. I will inspect this and supply a updated
patch.
Ralf
3) Ralf's patch for objdump/cygwin crashes on auto-imported libs
Nick Clifton has applied a patch for a similar problem, I will look if this
solve this already.
I was wrong, it was Laurent Pinchart, who has applied this patch.
This patch does not help in this case. I will inspect this
1) Ralf's removing unused _nm_ symbol exports fix
Relating to the thread
http://sources.redhat.com/ml/cygwin-apps/2002-04/msg00433.html i've updated this
patch to the latest cvs release.
--
2002-04-25 Ralf
Hi Charles,
(*) tentative because I can't actually test it myself against HEAD,
given the pre-existing problem with binutils HEAD on pe386.
The unwanted symbols, which this patch avoid, seems to be exported in some
packages. When this patch is applied, perhaps it makes sense to update the
();
-
2002-04-30 Ralf Habacker [EMAIL PROTECTED]
* ssp.c (run_program): Added time stamp printing in verbose mode.
Regards
Ralf
So linking by ordinal only will help you a little. rebinding and
rebasing your .dll's will help much much more.
.. which has to be analysed. Has anyone a working bind app ?
One could be found at
http://www.geocities.com/shewitt_au/speedload_files/speedload.html
Ralf
One could be found at
http://www.geocities.com/shewitt_au/speedload_files/speedload.html
I have tried to rebind ld created apps and applications with this and a self
written rebind app and got a problem.
rebind does only patch the first IAT entry, if the dll is created with ld. The
others
a self
written rebind app and got a problem.
rebind does only patch the first IAT entry, if the dll is created with
ld. The
others are set to zero
Rebinding for example the cygwin1.dll to some natvie windows apps
works, so this
seems to be an ld incompatiblity.
Does
Ok, I see what it does. Doesn't it have to do that for each reference to
the auto-imported variable?
For each auto-imported variable an IMAGE_IMPORT_DESCRIPTOR and an
IMPORT_THUNK_DATA element is necessary.
If so, then heavy use of an imported variable could make the
INT and IAT quite large
A patch to use hint ordinals when linking by name would be _very_ useful
though, as that would
a) give the performance benefit you are looking for
b) allow backward compatible library versioning as link-by-name does.
But as I stated already, this needs an ld switch to enable/disable ordinal
Well then, this is only half the puzzle. I can see what you gain from
such a patch, but as Chuck as indicated, it will cause -major-
difficulties in management.
Do you have read the rules I have stated for kde ?
A patch to use hint ordinals when linking by name would be _very_ useful
In theory, it looks good. However, have you tested the following:
a) build a dll using an unmodified ld.
b) build an app that uses that dll, and which accesses both a function
export and a data export from the dll.
c) rebuild the dll using your modified ld.
d) does the app still work,
In theory, it looks good. However, have you tested the following:
a) build a dll using an unmodified ld.
ls /usr/i686-pc-cygwin/bin/ -l
lrwxrwxrwx1 1002 Kein 26 Apr 19 07:49 ar.exe -
/usr/bin/ar.exe
lrwxrwxrwx1 1002 Kein 26 Apr 19 07:49 as.exe -
Ralf Habacker
-Original Message-
From: Charles Wilson [mailto:[EMAIL PROTECTED]]
Sent: Saturday, April 27, 2002 6:55 PM
To: Ralf Habacker
Cc: Kde-Cygwin; Cygwin-Apps; Binutils
Subject: Re: cygwin ld import library issue fix (removing unused _nm_
symbols)
Ralf Habacker
A patch to use hint ordinals when linking by name would be _very_
useful though, as that would
a) give the performance benefit you are looking for
b) allow backward compatible library versioning as link-by-name does.
But as I stated already, this needs an ld switch to
Hi all,
one of the biggest problems with kde 2.2.x currently is the very bad loading
time of applications and dll's, I've investigated some time to analyse this. On
this way I recognized, that runtime linking using symbol names is one of the
major time eater.
At first I have tried to estimate
1. Currently I' have a working solution for binutils 20011002 using a
specific import library create with an -out-implib-ordinal option,
which contains only ordinals and no symbols in the
IMPORT_DESCRIPTOR_BY_NAME structure. (The patches and testcase are appended)
The previous patch contains
Charles Wilson writes:
Any comments ?
Yes: compatibility. The problem with ordinal linking is, suppose
version 1 of a DLL has the following exports:
func_one 1
func_two 2
var_one DATA 3
and you link your executable to that dll by number.
Now, the vendor releases a new version of
Ralf Habacker wrote:
I'm thinking about creating to areas, an internal and an external.
New releases of kdelibs and perhaps kdebase for example are build together. So
ordinal linking is not problem. - internal area. Any other app may
be linked by name - external area.
That would cause
If you use a .def file to generate your DLL, will the auto-import stuff
get added to it? Can auto-import even work, if you're linking by
ordinal -- I thought the _nm_ hints were based on the symbol name,
no, the symbol name was build from the undef section, if a corresponding
If *you* release new compatible libs with the ordinals different from
the current libs, *my* application breaks. Or, you might get ripple
effects: what if I distribute a dll that depends on KDE's libs, and Bob
has an app that depends on my dll? Bob's app breaks because my dll is
The PE spec (as I read it) indicates that as long as a name is included
(ie it's not link-only-by-ordinal) then ordinals can change and nothing
will break.
It's only when the only link information is the ordinal that problems
will appear.
Or ld has a switch to explicit use ordinals (see
OTOH, if you've linked by ordinal, and then you strip symbols
-- are the
names of the imports still retained?
The symbols are removed, but in the _nm_vector the names are still retained.
Ralf
Ld rules:
1. By default ordinal linking is disabled
2. Add an ld option to enable ordinal linking.
As ordinal the hint number is used. (Could this have any unknown
side effect ??)
ordinal = hint number + 1.
How should such an option be named ?
--enable-ordinal-link ?
), exp-internal_name, ,
Any comments ?
Regards
Ralf Habacker
Hi Danny,
Yes, this looks very nice, but does it works against current CVS?
This patch is a minor change, which could be reviewed easy, but I have got
trouble using the current cvs head (binutils 2-12.xx) release from
sources.redhat.com.
It produces undefined symbols compiling dll/apps and
datasize; j += 4)
{
int ordinal;
char *member_name;
bfd/ChangeLog---
2002-04-25 Ralf Habacker [EMAIL PROTECTED]
* peigen.c (pe_print_idata): bugfix for segfault in
displaying auto-import image-import
-Original Message-
From: Ralf Habacker [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 26, 2002 12:09 AM
Any comments ?
Looks reasonable to me (on first glances). I'll try and have a closer
look this weekend if no-one else does.
Perhaps it helps, if I tell some details
Do not use C++ style comments in C code. It is non-portable.
This is an updated patch against the current cvs release and without c++
comments and a (I hope) propper changeLog entry.
2002-04-25 Ralf Habacker [EMAIL PROTECTED]
* pe-dll.cc (autofilter_symbolprefixlist): don't
On Thu, Apr 25, 2002 at 01:32:47PM +0200, Ralf Habacker wrote:
Hi Danny,
Yes, this looks very nice, but does it works against current CVS?
This patch is a minor change, which could be reviewed easy, but I have got
trouble using the current cvs head (binutils 2-12.xx) release from
* emultempl/pe.em (gld_${EMULATION_NAME}_place_orphan): Likewise.
Then this file could only be affected
When you take a look at the following changelog entry I assume, that this isn't
the problem, because there are only 4 changed lines, much more changes
ld was broken between 16 Dec (works) and 17 Dec (doesn't). The breakage was
reported to binutils list in January. I think, the problem is with merging of
sections in pe-dll.c in make_head() when making implib.
Another question: Does bfd have a debug mode or something else ?
Ralf
--- Ralf Habacker [EMAIL PROTECTED] wrote:
Can anybody tell me which cvs version is the last stable ? I
have tried to
checkout binutils with date 2001/12/31, but got compiling errors.
Compiling errors are fixed (was an overseen cvs conflict, but the problem
still
remains
ld checks the symbols in the shared libs during compile time to see
if it can
resolve all symbols and appearantly also detects duplicated
symbols. On Linux
it is not necassery impossible to have two libs that define the
same symbols.
E.g. this feature can be used to override the malloc
1. When someone build a shared lib on linux and uses a static lib, are the
symbols of the static lib automatically exported ?
Yes, using a static lib is no different than compiling that code
directly into your codebase.
Thats the behavior we have on cygwin, isn't it
2a. If yes, and
2b) set an option like --export-libs=* or something else
2c) identify the libs to export and set an option like
--export-libs=lib1,lib2,
Ups, I have overseen some errors in the logic above.
Additional Danny has used --exlude-libs, so the logic must
be negated
2b) set an option like
From: Robert Collins
Sent: Sunday, April 14, 2002 9:43 AM
Again, the ...= came from you, Rob. So, what's the
difference between
...= and ...=no or ...=unsupported (or
...=yes, for that
matter). And which do we want/need?
We want ...=. In both locations.
I'll test the
I'm using a special patched ld (based on the
recent official
ld) which rejects exporting of all imported
libs with a one
line patch
binutils/ld/pe-dll.c:234
/* Do not specify library suffix explicitly, to
allow for
dllized versions. *
static autofilter_entry_type
I' ve send this mail original to cygwin, because I was told to use the cygwin list, if
not talking about cygwin
distributed apps, but I don*t know I you are listening to cygwin, soo this is a
resent. :-)
Hi all,
I've recently installed the DocBook text processing system under CygWin.
This
Ralf Habacker wrote:
Robert Collins wrote:
Quoting from the fink site (it was handy):
The current development branch: This is the development version that
will some day be released as libtool 1.5. It has resulted from the merge
of 1.4 and the MLB. It supports C, C++ and Java (via gcj
Message -
From: Ralf Habacker [EMAIL PROTECTED]
Does anyone have an idea for fixing this ? I have no problem to fix
this, if somebody could
give me a direction where I have to look on.
Use linux or get the KDE team to fix their makefiles. You _could_ try
the cygwin=case_insensitive
-Original Message-
From: Robert Collins [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 04, 2001 10:14 AM
To: Ralf Habacker; Cygwin-Apps
Subject: Re: problem with make
- Original Message -
From: Ralf Habacker [EMAIL PROTECTED]
Does anyone have an idea for fixing
99 matches
Mail list logo
