note on command line installer
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 has an arm fracture, which results in a week spend in a hospital and has eaten my preserved time for the installer) and other reasons for this. I appreciate your work on this installer very much and I'm using this installer still for kde-cygwin, but I recognized that with the current code base, implemeting a command line installer would costs too much time I don't have yet, so I'm not able to work on this now (this may be change in the future, but I can't see this at this time), but I like to give some report so that others, how may benefit from this work. The main problems with the recent code base I see are 1. the intermixing of gui and core functionality. You have written about a minimal way to implement new applications using all files in one directory, but this is one of the main problems. If someone implements a command line installer, he is only interested on the core stuff not the gui stuff. The intermixing makes it very hard to see what is gui and what is core, and probably gui and other patches will be applied on wrong places, which increases needed bug fixing efforts. 2. The high abstraction of the api. In the last two years I have analysed and patched some of the kde sources and I have recognized this as a relative easy task because of the very high clearness of this implementation. With the cygwin installer sources sometime I felt lost, which makes it very hard to understand, whats going on and where to patch. Because it seems to be a problem to separate the gui from the core in the current implementation, the easiest thing would be to start new from scratch by using all usable code and classes from the current implementation with a clear design. BTW: Currently I'm using a shell based command line setup utility, which fullfilles most my my needs. If there are any interests for this let me know. Regards Ralf
Re: .rdata section in Cygwin executables?
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 and is only 1k in size. .rdata is a section where read-only data, such as constants, is stored. Most modern OSes and toolchain try to put as much info as possible to read-only segments of binary image because it reduce memory required by programs to run (when program is fork()ed, for instance, read-only pages may be shared between processes) In case of using gcc 3.3x and using auto-imported vars, you should use the '-fdata-sections' flags for compiling sources because otherwise these variables are not detected as variables. See http://sources.redhat.com/ml/binutils/2003-10/msg00256.html for more infos. Just a note. Ralf
AW: HEADSUP: cygserver now has MSG, SEM and SHM support
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 Cygserver isn't running) not only set errno to ENOSYS, but they also raise a SIGSYS. So it's crucial that your code handles that signal. At least, it should ignore it (signal(SISYS, SIG_IGN)). Harold for the Xserver that means, that the shm initialisation code has to be changed to the detecting code used by FreeBSD and friends (CheckForShmSyscall() in Xserver/Xext/shm.c and Xserver/Xext/xf86bigfont.c) The cygipc-related stuff could then be removed in both files. Ralf
AW: AW: [PATCH] setup - help and local dir commandlineoptionswasRe: Setup Command Line Options
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 line applications. The above suggested design could then be implemented step by step (which means that the current windows message stuff will be used) I think you'll find that that is a hard approach to take, as commandline apps don't have an event loop unless you get into creating a hidden window and so forth. The minimal engine API I proposed is a reuse strategy, but various code will have to be converted as you go. agreed, I assumed that the event loop has to be in the gui stuff, 3. While some classes of the recent code base are gui independent, there are others which contains gui and non gui stuff intermixed, which should be cleaned up/separated before or while moving to a implementing. Yes. Needed changes: 1. defining a rule for class/file naming scheme. There some packages which http://www.cygwin.com/ml/cygwin-apps/2003-03/msg00750.html or GUIDELINES in the source code. Thanks 2. remove intermixing of GUI and non gui classes in one file Yes - I addressed this in my roadmap. AntiVirus.cc for example contains a class AntiVirusPage, which provides the gui stuff and AntiVirus for the non gui stuff. If the functionality of this classes would be separated in such a manner, that the gui class(es)s contain only gui related stuff, the gui related stuff could be commented out by a C define. Unfortunally this isn't true in the most cases I found. Using this files in a command line tool need reorganisation of such files, which could be done in three flawors: 2.1. reassign the classes functionality and comment out gui stuff with #ifdef USE_GUI ... #endif and not defining USE_GUI for command line apps or 2.2. move the gui stuff in a new file named like the containing major class for example AntiVirusPage.cc for the AntiVirusPage class. 2.3. leave the gui file naming like it is and create a new similar named file for the engine containing the non gui stuff in a different dir (like I have done in the proof of design) A different dir isn't needed for now. 2.1 isn't acceptable, as I don't want to have to compile classes twice. agreed 2.2/2.3 are essentially the same and as long as a different dir isn't prematurely used are both fine. see below Yes. I sketched out a fairly minimal development path to generate a commandline setup that doesn't involve forking the engine code. You haven't commented on the approach, rather you appear to have just ignored it completely. Why ? What is wrong with separating files into different dirs in a proof of design to get a better overview of the dependencies. May be you are very familiar with this code so you don't need something like this, but it helped me very much to get a clearer image about the dependencies. This is no forking. Also see 2. for the need of some separation. CVS doesn't have the facilities for tracking movement of source files properly. 1. This may a reason for not separating, but there are several solutions a. you can add a move hint like class AntiVirusPage moved to/from AntiVirusPage.cc in the related files log message a. we are already forced yet to move classes to other files like the class AntiVirusPage and other. Until the engine is separate, and complete, we won't know for sure what is in the engine, and whats in the UI. For instance, will we use res.rc in the commandline, or switch to gettext? (I suspect res.rc in the commandline). Does that mean we need to split res.rc? or do we just ignore the overhead. The only usable parts from res.rc are the stringtables, but this isn't very much, so this duplicating may not be a major problem. Regardless of the used way I think we should define a generic function to retrieve language strings, so that we can implement whatever we want. Additional there is the question, should the engine code reports clear text messages or only return values, so that the message text in only located in the frontends. Providing engine related error messages in the engine may reduce duplication. What about let returning the engine error codes and providing an additional engine function to retrieve the error messages ? gettext versus res.rc - I have to think a little more about this. 2. In general this are reason to separate very early because it enforces the developer to think about the context where the code belongs. At first this requires a little more efforts to get thins running, but I think this is worth while. (This is exactly the reason why I have moved the files a different dir in the provided sources, I have already moved about 80% of the code) So do what you like to say ? Should we separate now or not ?
AW: [Patch] Resizing fixes
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 it's initial size. APplied. Please submit patches with diff -up always - they are much easier to read, and more robust at applying to altered source. I've tried the resizing stuff and it is really great. While i'm working with this, I've got two ideas for improving the general selection window. The first one is to split the list into two parts: a category window on the left side and a package list on the right (like yast on suse linux) and second a search field to search for a specific package. I see some advantage of this: 1. The navigation through packages would be a easier because the items on the category list are scollable independantly from the package list. 2. the package windows does not need a horizontal scrollbar, because the package informations are printed on the window bottom when selecting a package, this reduces the needing scrolling operations to read the package info. In short: The user does see more information at one time. 3. The search field allows a very fast access to each individual package. category packages release +--++-+ |+All(2) || x [cygwin-doc]1.2-4 | |+Admin|| - docbook-xml42| |+Archive || - docbook-xsl | |+Base || (1) | |+Database || | |+Devel|| | |[Doc] || | |+Editors || | |+Games|| | | || | | ... || | +--+| | search packages | | +--+| | | || | +--++-+ package info +-+ |cygwin specific information, including man pages and | |User's guide | +-+ (1) this icon could be toggled through install (with choosing the requested releases), uninstall, reinstall, upgrade,... (2) I don't think that it makes sense to add a install, uninstall button for each category. Makes it sense to install *all* databases or *all* editors ? I don't think so. Upgrading all packages in this category makes more sense, i think. Only a little note. BTW: Currently I'm very busy with the command line version of setup, afterthat I probably will be able to contribute to this. Ralf
AW: AW: [PATCH] setup - help and local dir command lineoptionswasRe: Setup Command Line Options
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 concentrated only to get a command line version initial running, so I've removed the not needed gui stuff. Currently I can't send in a patch for this, because I have splitted the relating engine files into subdir and build a static library to allow file including checks, although the binariy and sources could be downloaded here: binary http://kde-cygwin.sf.net/snapshots/enginetest-0.0.1.exe. source http://kde-cygwin.sf.net/snapshots/setup_new-0.0.1.tar.bz2 Sounds like you've gone too far too fast. I don't have the time to review a non-delta set of changes. Particularly ones that throw away a lot of code (the gui) that -must- be retained. I think there are some mißunderstandings. This code is *not* ready for reviewing. This is a step before, because while I'm working on this I have found some specification needs of the basic design. Let me explain what I mean: 1. Definition of the term engine. Actually I understand under the engine all classes, functions and structures of the recently setup installer, which could be used are a common base to build gui or command line based installer. This definition may differs from your view, sow we have to adjust this. I don't have a particular preference, but I've listed those in likely order of difficulty (for migration from the current code base) - and we should only use one approach. If we want to use windows messages, I suspect we want to wrap the engine in an adapter - as the command line tool won't have a message loop. * never throws exceptions: all errors must be handled in the engine, and propogated to the UI via the callback mechanism. (We need a callback for engine termination.) The UI needs to be able to: * query the engine for the available options * hand user details into the engine * retrieve structured data (ie. the list of sites) * attempt to action a given stage of the engine. * display progress of long running tasks. 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 line applications. The above suggested design could then be implemented step by step (which means that the current windows message stuff will be used) 3. While some classes of the recent code base are gui independent, there are others which contains gui and non gui stuff intermixed, which should be cleaned up/separated before or while moving to a implementing. Needed changes: 1. defining a rule for class/file naming scheme. There some packages which are written lowercase (1) and some mixed (2). What's the prefered one ? some examples (this is mainly for me to learn what the current strategy is) typeclass file 1 packagemeta package_meta(.h|.cc) 1 packagedb package_db(.h|.cc) 2 UserSetting UserSetting(.h|.cc) 2 AntiVirus AntiVirus(.h|.cc) (see topic 2) AntiVirusPage AntiVirus(.h|.cc)(see topic 2) 2. remove intermixing of GUI and non gui classes in one file AntiVirus.cc for example contains a class AntiVirusPage, which provides the gui stuff and AntiVirus for the non gui stuff. If the functionality of this classes would be separated in such a manner, that the gui class(es)s contain only gui related stuff, the gui related stuff could be commented out by a C define. Unfortunally this isn't true in the most cases I found. Using this files in a command line tool need reorganisation of such files, which could be done in three flawors: 2.1. reassign the classes functionality and comment out gui stuff with #ifdef USE_GUI ... #endif and not defining USE_GUI for command line apps or 2.2. move the gui stuff in a new file named like the containing major class for example AntiVirusPage.cc for the AntiVirusPage class. 2.3. leave the gui file naming like it is and create a new similar named file for the engine containing the non gui stuff in a different dir (like I have done in the proof of design) Here a general decision of the maintainer is required. There may be more issues, but I think for now is is enough and I'm waiting for your comments. Yes. I sketched out a fairly minimal development path to generate a commandline setup that doesn't involve forking the engine code. You haven't commented on the approach, rather you appear to have just ignored it completely. Why ? What is wrong with separating files into different dirs
AW: AW: [PATCH] setup - help and local dir command line optionswasRe: Setup Command Line Options
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 interface.
Are there any other requests or hints about the design ?
I've roughed stuff out here before, I think. Anywhere, here goes a quick
brain dump.
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
concentrated only to get a command line version initial running, so I've
removed the not needed gui stuff. Currently I can't send in a patch for
this, because I have splitted the relating engine files into subdir and
build a static library to allow file including checks, although the binariy
and sources could be downloaded here:
binary http://kde-cygwin.sf.net/snapshots/enginetest-0.0.1.exe.
source http://kde-cygwin.sf.net/snapshots/setup_new-0.0.1.tar.bz2
I have done the following steps to get a compiled exe.
cd .../setup_new
mkdir debug
cd debug
../configure CXX=g++ -mno-cygwin CC=gcc -mno-cywin
cd engine
make
This will build the library and the enginetest applications, which has some
basic functionality like:
enginetest-0.0.1.exe --query --all - list all installed packages
enginetest-0.0.1.exe --query --list packagename - list all files of the
installed package
The main problem after finding where to remove/hack the gui related stuff,
is to detect the needed objects/method for the requested operation. Is is
sometimevery hard to follow the current code base and some light for this
would be nice, so it there is someone how can give me some more informations
(ideal would be some basic coding like mentioned below) it would be nice.
For the currently implemented (and some more I'm going to implement)
functions the used objects/methods are listed below
snip
if (QueryPackageOption) {
if (ListAllPackagesOption) {
packagedb db;
db.listAllPackages(cout); [new method of packagedb]
}
if (ListFilesInPackagesOption) {
packageversion pkg = cygpackage::createInstance(argv[optind]);
String s = pkg.getfirstfile();
while (s.size() 0) {
cout s.cstr() endl;
s = pkg.getnextfile();
}
}
}
/*
site list handling
- list all mirrors
- allow user to choose one mirror
related functions/classes/methods
// clear selected mirror
site_list.clear ();
get_site_list(http://sources.redhat.com/cygwin/mirrors.lst;); [uses
parameter instead of using LoadString()]
// iterate throug the site lists.
for (SiteList::const_iterator n = site_list.begin (); n !=
site_list.end
(); ++n)
// set used mirror
site_list = all_site_list[mirror];
*/
/*
install/reinstall/upgrade/remove packages
static BoolOption DownloadOption (false, 'D', download, Download
from
internet);
static BoolOption LocalOption (false, 'L', local-install, Install
from
local directory);
static BoolOption InstallOption (false, 'I', install, Install from
internet);
or
static StringOption SourceURLOption (false, 'S', source-packages,
source package path (http,ftp,file,rsync,...));
static BoolOption InstallOption (false, 'i', install, Install);
static BoolOption InstallOption (false, 'e', erase, erase package);
static BoolOption InstallOption (false, 'u', upgrade, upgrade
package);
static BoolOption InstallOption (false, 'f', fresh, reinstall
package);
if (DownloadOption)
source = IDC_SOURCE_DOWNLOAD;
else if (LocalOption)
source = IDC_SOURCE_CWD;
else
source = IDC_SOURCE_NETINST;
Taskhandling
packagedb db;
db.task = source == IDC_SOURCE_DOWNLOAD ? PackageDB_Download :
PackageDB_Install;
How it goes on
*/
Any comments ?
Cheers
Ralf
RE: [PATCH] setup - help and local dir command lineoptionswasRe: Setup Command Line Options
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 provide: The patch for main.cc and localdir.cc The updated changelog Here is it. Ralf Changelog 2003-10-27 Ralf Habacker [EMAIL PROTECTED] * main.cc (HelpOption): New instance. (main): Added help command line option handling. * localdir.cc (LocalDirOption): New instance. (LocalDirSetting::load) allow setting localdir from command line. help_and_local_dir_cmd_options.patch Description: Binary data
AW: AW: [PATCH] setup - help and local dir command line optionswasRe: Setup Command Line Options
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 interface. Are there any other requests or hints about the design ? I've roughed stuff out here before, I think. Anywhere, here goes a quick brain dump. I need more time to think about what you have written and how to start with which class, but let me ask one question now, perhaps you can fix this: Have you tried to compile the inilint example in the last time ? I have to add so many additional files because of dependencies and the last one 'threebar.o' one introduce a gui class, so the example could not be build as console application :-( These one I have to add package_version.$(OBJEXT) package_db.$(OBJEXT) \ cygpackage.$(OBJEXT) package_meta.$(OBJEXT) package_source.$(OBJEXT) \ compress.$(OBJEXT) compress_gz.$(OBJEXT) compress_bz.$(OBJEXT) hash.$(OBJEXT) log.$(OBJEXT) \ mklink2.$(OBJEXT) mount.$(OBJEXT) msg.$(OBJEXT) state.$(OBJEXT) dialog.$(OBJEXT) script.$(OBJEXT) download.$(OBJEXT) threebar.$(OBJEXT)\ ... Ralf
[PATCH] libtool patch for direct-linking-to-dll
Hi all, appended is a libtool patch (based on the current official libtool release 2003-02-16 for enabling the direct-linking-to-dll functionality, which was applied a few weeks ago to the binutils cvs release and give a major linking time improvement especially for big applications and/or libraries. See http://sources.redhat.com/ml/binutils/2002-12/msg00396.html for further details. Please note that this patch currently works only with the current cvs ld release and should be used as a prelimary patch, because it does not check, if ld does support this functionality. It is enabled by default. A way for checking this should be discussed. I see two ways for dealing this with: 1. Adding an ld option like --disable-dll-linking or so, which existance could be checked in libtool, autoconf or configure (currently I don't where the best place is). This option isn't a must be and it is only used for detecting the functionality, because the necessary ld changes are backward compatible. 2. Using the ld's release time 2003 $ ld -v GNU ld version 2.xx.yy 2003... 3. Another great idea, I currently do not have Any hints or comments ? 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 'archive_cmds'. * ltmain.sh: (install cygwin/mingw): added installing of shared libraries into 'bin' dir (uninstall cygwin/mingw): added uninstalling of shared libraries Ralf libtool.m4.dif Description: Binary data ltmain.sh.dif Description: Binary data
RE: [ITP] rebase (resend)
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
RE: [ITP] rebase
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
RE: [ITP] rebase
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
RE: [ITP] rebase
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. Ralf
RE: Integrating Ralf's rebase into setup.exe
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 base address to be an extra DLL size amount lower and #2 causes the base address to be an extra DLL size amount higher. Applied and checked in. Ralf
[patch] auto-import-dll libtool related patch
Hi all, relating to the auto-import-to dll patch in http://www.cygwin.com/ml/binutils/2002-12/msg00396.html I have added an minor patch to prevent importing a dll more than one time, which otherwise results in multiple symbol definition errors. Especially in libtool environments I have 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): added code to prevent importing a dll multiple times. Regards Ralf ld-auto-import-dll-avoid-multiple-loads.patch Description: Binary data
RE: [patch] auto-import-dll libtool related patch
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 dll.dll - will fail without this patch while gcc -o xx.exe objectfiles -L. -ldll -ldll - will not fail Ralf
RE: Integrating Ralf's rebase into setup.exe
Hi Jason, The attached patch enables libimagehelper.a to be usable by C source too. Applied. Thanks for fixing this. Ralf
RE: Integrating Ralf's rebase into setup.exe
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
RE: Integrating Ralf's rebase into setup.exe
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
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
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
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
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
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
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
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
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 not 0.6. I thought it odd that 0.6 was missing. fixed. Created with cvs2cl and added to the cvs. Interesting tool -- I'd never heard of it before. See http://www.red-bean.com/cvs2cl/ If you check in all changed files with a single cvs call and same message, it will be gathered in a single change log entry. Ralf
RE: Integrating Ralf's rebase into setup.exe
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
Re: Integrating Ralf's rebase into setup.exe
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 include file imagehlp.h. After checking out just call $ make imagehlp and the lib is created. - the debug message printing is conditionalized with an internal debug flag, so by default the code does not print any debug messages. Regards Ralf
RE: Integrating Ralf's rebase into setup.exe
However, should we use the names libimagehlp.a and imagehlp.h? They clash with the mingw versions. Do you have a better name ? Ralf
RE: Integrating Ralf's rebase into setup.exe
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 could go ahead and say 'using namespace std;'. Oh, a few other niggles: why does Makefile have DOS line-endings fixed README needs a brief note about this 0.6 version. More than I have written in my last email ? And shouldn't there be a ChangeLog? Created with cvs2cl and added to the cvs. Ralf
RE: Uncompilable setup.exe... again
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) LDFLAGS=-L/usr/lib/w32api configure ... or CFLAGS=-L/usr/lib/w32api configure ... Ralf
RE: Doxygen
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 want to use the _WIN32 code then add to the #ifdef _WIN32 also a check for __CYGWIN__. But this should be done on your prior knowledge that this is really the way it must be done. Ie you have to check the source by yourself and decide where _WIN32 is needed and where not. You should not be using _WIN32 in the Cygwin port because the Qt library will not deal with UNIX filenames properly. You can use the version of the Qt files from kde-cygwin and copy those over the files in doxygen. That should work. I have tried, it could be compiled out of the box with qt 2.3 including doxywizard. Ralf
RE: Please review ,vote, and I will review
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: http://www.trolltech.com/developer/download/tmake.html Do you have recognized that starting with version 3.0, Qt includes qmake, an improved incarnation of tmake, which is currently available in the cygwin port of qt3 on the kde-cygwin project on http://sourceforge.net. Additional some time ago Nicolas Wourms has announced, that the he is going to make a cygwin package for qt3, so I think this had to be checked. Ralf
ld seg fault while creating import library
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 library. For each object file in the import library a bfd object is created. In recent releases this function eats about 30 KB for each object file. The qt2 import library contains 12078 objectfile, which needs 350 MB only for generating the import library and causes the seg fault in the descripted case. $ nm /usr/local/lib/qt2/lib/libqt.dll.a | grep .o: | wc -l 12078 The related functions are in pe-dll.c pe_dll_generate_implib(def, impfilename) make_one (exp, parent) bfd_create() _bfd_new_bfd() !!! These are the functions in which the memory is allocated bfd_zmalloc() objalloc_create() bfd_hash_table_init() !!! With the help of a little malloc debugger under http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/kde-cygwin/tools/mem_watch/which i can see, that the memory used by make_one() and subfunctions need tweny kilo bytes more than the kde-cygwin binutils, which is based on the official 20011102 release. It seems that there are two additional malloc calls in the objalloc related functions in libiberty. make_one (exp, parent) new old malloc(4064)=1ade29d8 [00487a11]malloc(4064)=0e7e5ec8 [0047bb95] malloc(20)=1ade39c0 [0047ea54] malloc(20)=0e7e6eb0 [00472e1c] malloc(152)=1ade39d8 [00440fac] malloc(132)=0e7e6ec8 [0043d7cc] malloc(12)=1ade3a78 [004878b0] malloc(12)=0e7e6f50 [0047bad1] malloc(4064)=1ade3a88 [004878d1]malloc(4064)=0e7e6f60 [0047bae7] malloc(12)=1ade4a70 [004878b0] !malloc(4064)=1ade4a80 [004878d1] !malloc(16216)=1ade5a68 [004879b4] malloc(8)=1ade99c8 [00440f28] malloc(8)=0e7e7f48 [0043d748] malloc(44)=1ade99d8 [0047ea54] malloc(44)=0e7e7f58 [00472e1c] malloc(24)=1ade9a08 [0047ea54] malloc(35)=0e7e7f88 [00472e1c] malloc(18)=1ade9a28 [0047ea54] malloc(18)=0e7e7fb0 [00472e1c] malloc(30)=1ade9a40 [0047ea54] malloc(41)=0e7e7fc8 [00472e1c] malloc(8)=1ade9a68 [0047ea54] malloc(8)=0e7e7ff8 [00472e1c] malloc(160)=1ade9a78 [0047ea54] malloc(160)=0e7e8008 [00472e1c] malloc(8)=1ade9b20 [0047ea54] malloc(8)=0e7e80b0 [00472e1c] malloc(4)=1ade9b30 [0047ea54] malloc(4)=0e7e80c0 [00472e1c] malloc(160)=1ade9b40 [0047ea54] malloc(160)=0e7e80d0 [00472e1c] malloc(8)=1ade9be8 [0047ea54] malloc(8)=0e7e8178 [00472e1c] malloc(4)=1ade9bf8 [0047ea54] malloc(4)=0e7e8188 [00472e1c] malloc(160)=1ade9c08 [0047ea54] malloc(160)=0e7e8198 [00472e1c] malloc(8)=1ade9cb0 [0047ea54] malloc(8)=0e7e8240 [00472e1c] malloc(4)=1ade9cc0 [0047ea54] malloc(4)=0e7e8250 [00472e1c] malloc(160)=1ade9cd0 [0047ea54] malloc(160)=0e7e8260 [00472e1c] malloc(8)=1ade9d78 [0047ea54] malloc(8)=0e7e8308 [00472e1c] malloc(26)=1ade9d88 [0047ea54] malloc(36)=0e7e8318 [00472e1c] !malloc(384)=1ade9da8 [00440f67] !malloc(20)=1adea030 [00440f28] Any ideas ? Ralf
RE: setup.exe and replacing of in-use files
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 this for already released files :-(, so are there any other possibilities to solve this problem ? PRC-Tools tells its users to point setup.exe at http://prc-tools.sourceforge.net/install/ (i.e. our Sourceforge *website*) and then uses HTTP redirects therein to map whatever collective hallucination we'd like setup.exe to see into the reality of the Sourceforge file release system. For us, it's pretty simple: .../htdocs/install/.htaccess: RedirectMatch install/(.*[^/].*/.*) http://us.dl.sourceforge.net/sourceforge/$1 thanks for this hint, it works for me too. Please grant me one question with this redirect. Perhaps you can help me: This redirect requires a path like sf-project-name/file in the setup.ini. I've tried to change the above line into RedirectMatch install/(.*)$ http://us.dl.sourceforge.net/sourceforge/sf-project-name/$1 to avoid this preeceding sf-project-name but this doesn't work and the apache online help of mod_alias doesn't gave me enough infos to find the problem. Any ideas ? Ralf
RE: setup.exe and replacing of in-use files
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 tree in release/ From http://cygwin.com/setup.html#package_contents Packages are grouped by directory under release. The directory name is the same as the package name. For example, the boffo package will live in the boffo subdirectory. Exceptions to this rule are historical. All new packages will follow the rule of package name == directory name. However, for closely related groups of packages, it is acceptable to use a heirarchical tree under release/: If upset is used for parsing the packages under /release how should it distinguish multiple setup.hint files if they are not located in different dirs ? Ralf
RE: setup.exe and replacing of in-use files
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 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 this for already released files :-(, so are there any other possibilities to solve this problem ? Ralf
RE: setup.exe and replacing of in-use files
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 'kde-x' -- so the line should be kde-x not kde_x ? not kde-x-1.3 Ralf
RE: setup.exe and replacing of in-use files
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 them. For what should this be good, when I cannot have write access to this folder ? The download area is completly managed by php scripts using a postgresql database and they does not allow direct manipulation. 2. sourceforge is now only a service and no more an open source application, so there is no possibility to change the php sources to implement such a functionality. It seems curious, but it is not possible to delete or rename files in the download area, so the consequence is, that there is no chance to correct done decisions :-( 3. if there would be a way over the sourceforge stuff I don't like to send a support request for each update I like to do and it seems the don't like to implement such feature, for which I have send in a feature request without any replay :-( Have you tried logging in to your shell account and manually create the subdirs? Yes, of course, but unfortunally project members have no shell access to the download area because of the database synchronisation problems. Also, you could just use Upset on your own machine to generate the ini file, then strip the directories away... This may be a solution, but isn't upset a perl script ? Currently that may be a little problem for me because I'm not a perl expert, but I will take a look. Regards Ralf
RE: new setup.exe crashes with kde's setup.ini
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
RE: new setup.exe crashes with kde's setup.ini
[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 download mirror system Sourceforge introduced on 2002-05-03. As I wrote when I changed prc-tools's .htaccess to deal with this: Update the redirect to cope with Sourceforge's new download mirror system. You'd think they could have implemented that without breaking all the old URLs, but no... They need to tell people to use http://us.dl.sourceforge.net/sourceforge/kde-cygwin/setup.ini (or similar) instead. Thanks for this hint, I will update the website. That works fine in 2.249.2.4 but has a parse error in the 2.253 snapshot, perhaps because of the blank line at the end. (Hey, nice parse error message! That'll help if the bizarre parse error prc-tools's setup.ini was intermittently getting recurs.) John
RE: binutils status ?
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] * peXXigen.c (pe_print_idata): fixed some seg faults on printing import tables with auto-imported symbols. I have applied this patch, with Nick's permission. The patch did apply cleanly but I did have to do a substantial amount of cleanup on spacing issues. The indentation was really off, AFAICT. Thanks for this hint. I'll review the documentation to see what I have done wrong, so the next patches should be better in this way. Regards Ralf
RE: [PATCH] pei386: make --enable-auto-import default
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 them. That means, adding --enable-auto-import to the command will only suppress the warning, isnt' it ? Ralf
RE: setup releases
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 encourage you to actually read the cvs data related to setup.exe to actually understand what is going on. If you want more indepth information then I would encourage you to do a search on the entire archive re: setup.exe (search target). Seeing the whole forest is much more informative than seeing just a single tree. Thanks for this hint. Ralf
RE: question about objdump output format ?
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 import table lines, added Bound-To comment. I hope, the changelog entry is clear. It may be, that the indents ate 100% pure, please correct if necessary Unfortunately I have some problems with this patch: * It does not apply against the current sources in the CVS repository. In fact it is not even close. There has been some recent work on this code by Laurent Pinchart [EMAIL PROTECTED] which chnages the layout for the code. This patch is based on Laurants work (peXXigen.c cvs version 1.7) and(1) on the patch in http://www.cygwin.com/ml/cygwin-apps/2002-05/msg00346.html, which fixes some additional seg fault fixes relating to auto-import. It is called objdump_ai_segfault_2.patch on the top of this mail and is also based on Laurants work. So this is the way: 1. apply objdump_ai_segfault_2 patch 2. apply objdump_no_double_import_table_printing patch. I have send patch (1) to binutils and cygwin-apps, but unfortunally noone has checked this in. * It appears that although the statement: fprintf (file, _(\tvma: Hint/Ord Member-Name\n)); implies that a member name will be printed, if the top bit of the VMA is set, no name is output: if (member 0x8000) fprintf (file, \t%04lx\t %4lu, member, member 0x7fff); This is a problem because your patch changes the fprintf to: fprintf (file, _(\tvma: Hint/Ord Member-Name Bound-To\n)); So that readers might confuse the Bound-To address that is printed later on with the (non-existent) Member-Name. May I suggest that you change the fprintf for when the top bit is set to something like: if (member 0x8000) fprintf (file, \t%04lx\t %4lu none, member, member 0x7fff); This make sense * Your patch completely eliminates the loop starting: for (j = 0; j datasize; j += 4) I understand that this is the duplicate information that you are trying to avoid, but what if datasize is greater than 4 ? Would this not mean that extra information that should be displayed is no longer printed ? This loop does only the check for detecting differences beetwen the hint array and the import allocation table, One issue may be, printing the line The Import Address Table is identical or The Import Address Table (difference are found), which I have removed, because I currently see no other reasons than on bounded addresses and this is printed explicit. Any comments ? Given that the Bound-To addresses are being explicitly displayed, I do not have a problem with your patch removing this line.
RE: question about objdump output format ?
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 does not work) without th segfault patches. So what should I do ? The is a possibility, I can merge both patches and submit it as one, but this infringe a rule, that patches should cover only single issues because of easier testing, isn't it ? So should I merge the patches or what should I do ? Regards Ralf
RE: Problem with cygwin install.
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
RE: setup releases
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
RE: question about objdump output format ?
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 will change this, but let us see what Nick Clifton say about this Please go ahead and generate and submit a patch. Cheers Nick Here is the patch. It is based on the objdump_ai_segfault_2.patch, which I have send in before. Changelog entry for bfd dir -- 2002-05-22 Ralf Habacker [EMAIL PROTECTED] * peXXigen.c (pe_print_idata()): removed double printed import table lines, added Bound-To comment. --- I hope, the changelog entry is clear. It may be, that the indents ate 100% pure, please correct if necessary One issue may be, printing the line The Import Address Table is identical or The Import Address Table (difference are found), which I have removed, because I currently see no other reasons thant on bounded adresses and this is printed explicit. Any comments ? Regards Ralf objdump_no_double_import_table_printing.patch Description: Binary data
RE: setup releases
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 configure options documented on: http://sources.redhat.com/cygwin-apps/setup.html. That will produce a mingw executable. Thats for this hint. I assume someone would have this lib installed. Could anyone place such a file on someones homepage, for example on Chucks cygutils pages. It would save time not only for me :-) Ralf
RE: Problem with cygwin install.
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. Does anyone have some informations about how this extension works ? It seems noone, so it needs a little more time to analyse this bug, but I think I've catched this bug: The problem was, that in archive_tar::next_file_name() in case of filenames with the GNU long name extension a flag 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 === RCS file: /cvs/cygwin-apps/setup/archive_tar.cc,v retrieving revision 2.8 diff -u -3 -p -B -b -B -p -r2.8 archive_tar.cc --- archive_tar.cc 5 May 2002 04:02:00 - 2.8 +++ archive_tar.cc 26 May 2002 19:00:37 - @@ -168,6 +168,8 @@ archive_tar::next_file_name () memcpy (state.filename, state.tar_header.name, 100); state.filename[100] = 0; } + else if (state.have_longname) + state.have_longname = 0; sscanf (state.tar_header.size, %o, state.file_length); state.file_offset = 0; Any comments before submitting ? Ralf
RE: Problem with cygwin install.
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. Does anyone have some informations about how this extension works ? Ralf
FW: Problem with cygwin install.
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 have an idea, why this could happen ? The archive is valid, unpacking by
hand works.
It seems so, that this file was interpreted as a dir ...
mkdir.cc
snip
if (isadir)
{
if (CreateDirectory (path, 0))
return 0;
gse = GetLastError ();
if (gse != ERROR_PATH_NOT_FOUND gse != ERROR_FILE_NOT_FOUND)
{
if (gse == ERROR_ALREADY_EXISTS)
{
fprintf (stderr,
warning: deleting \%s\ so I can make a directory there\n,
path);
if (DeleteFileA (path))
return mkdir_p (isadir, path);
}
return 1;
}
}
or could this have anything to do with the file name length ? It is the longest
filename in the archive (103 characters).
-r--r--r-- Administratoren/Kein1789 2002-04-07 19:25:06
opt/kde2/share/doc/HTML/en/kdeprint/cupsserverconfig_serverencryptionconfig_serv
ercertific
ate_blurb.png
PackageProgress.gif
Description: GIF image
SetupWarning.gif
Description: GIF image
question about objdump output format ?
Hi all, the windows runtime linker allows rebinding of dll's and exe for which I have written a tool currently located on the kde-cygwin project on http://sourceforge.net/project/showfiles.php?group_id=27249. A side effect of this is, that objdump prints each line twice (the second line contains no additional infos), which blows up listing on bigger libs (for example about 35000 lines of 100860 for the kdecore dll from kde 2.2.2), so my question is, are there any objections for removing this ? 001540f0 0017f218 00189390 3934 DLL Name: qt-2-3.dll 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
RE: binutils status ?
3) Ralf's patch for objdump/cygwin crashes on auto-imported libs snip This patch does not help in this case. I will inspect this and supply a updated patch. Appended is a patch for ... see the ChangeLog entry. 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] * peXXigen.c (pe_print_idata): fixed some seg faults on printing import tables with auto-imported symbols. Regards Ralf objdump_ai_segfault_2.patch Description: Binary data
RE: binutils status
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
RE: binutils status ?
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 and supply
a updated
patch.
In peXXigen.c Line 1208 there is a case handling rebinded imports, which isn't
affected by Laurent's Patch.
/* If the time stamp is not zero, the import address
table holds actual addresses. */
if (time_stamp != 0
first_thunk != 0
first_thunk != hint_addr)
fprintf (file, \t%04lx,
(1) (long) bfd_get_32 (abfd, data + first_thunk - adj + j));
^^
this fails in case of rebinded apps or dll, that means first_thunk points into
the text segment
this printing should goes after laurent patch, when the different section is
loaded
fprintf (file, \n);
}
}
--- here starts Laurant's patch ---
if (hint_addr != first_thunk time_stamp == 0)
{
bfd_byte *ft_data;
asection *ft_section;
snip
Laurant: Can you give a hint how the line marked with (1) should be changed ?
Ralf
RE: binutils status
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 Habacker [EMAIL PROTECTED]
* pe-dll.cc (autofilter_symbolprefixlist): don't export
reimported functions.
(make_one): let create only _nm_.. for data symbols
--
$ cvs diff -ubBp pe-dll.c
Index: pe-dll.c
===
RCS file: /cvs/src/src/ld/pe-dll.c,v
retrieving revision 1.39
diff -u -3 -p -B -u -b -B -p -r1.39 pe-dll.c
--- pe-dll.c3 May 2002 13:48:55 - 1.39
+++ pe-dll.c20 May 2002 17:18:47 -
@@ -252,6 +252,8 @@ static autofilter_entry_type autofilter_
/* { __imp_, 6 }, */
/* Do __imp_ explicitly to save time. */
{ __rtti_, 7 },
+ /* Don't export reimported functions*/
+ { _nm_, 4 },
{ __builtin_, 10 },
/* Don't export symbols specifying internal DLL layout. */
{ _head_, 6 },
@@ -1793,8 +1795,11 @@ make_one (exp, parent)
quick_symbol (abfd, U (_head_), dll_symname, , UNDSEC, BSF_GLOBAL, 0);
quick_symbol (abfd, U (_imp__), exp-internal_name, , id5, BSF_GLOBAL,
0);
/* Symbol to reference ord/name of imported
- symbol, used to implement auto-import. */
- quick_symbol (abfd, U(_nm__), exp-internal_name, , id6, BSF_GLOBAL, 0);
+ symbol, used to implement auto-import.
+ (only for data symbols) */
+ if (exp-flag_data)
+quick_symbol (abfd, U(_nm__), exp-internal_name, , id6, BSF_GLOBAL,0);
+
if (pe_dll_compat_implib)
quick_symbol (abfd, U (__imp_), exp-internal_name, ,
id5, BSF_GLOBAL, 0);
--
Because revision 1.39 does not contain any functional changes and the patches
for 1.3.8 and 1.39 are the same (except some line offset), the tests I have
running in the above mentioned thread are valid.
revision 1.39
date: 2002/05/03 13:48:55; author: kazu; state: Exp; lines: +33 -33
* ld.h: Fix formatting.
* ldexp.c: Likewise.
* ldfile.c: Likewise.
* ldlang.c: Likewise.
* ldmain.c: Likewise.
* lexsup.c: Likewise.
* pe-dll.c: Likewise.
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.
peXXigen.c
revision 1.7
date: 2002/05/15 15:28:12; author: nickc; state: Exp; lines: +54 -3
Do not assume that the first thunk is located in the same section as the
import table. Instead check, and if necessary load the section containing
the thunk.
Ralf
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
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 following libs. dll count /bin/cygcrypto.dll 75 /bin/cygexslt-0.dll106 /bin/cygform6.dll 45 /bin/cyggdbm.dll 25 /bin/cyghistory5.dll 26 /bin/cygintl-1.dll 35 /bin/cygjbig1.dll 9 /bin/cygjpeg6b.dll 17 /bin/cygltdl-3.dll 31 /bin/cygmenu6.dll 34 /bin/cygncurses++6.dll254 /bin/cygncurses6.dll 74 /bin/cygpanel6.dll 14 /bin/cygpcre.dll 24 /bin/cygpcreposix.dll 26 /bin/cygpng2.dll 28 /bin/cygreadline5.dll 72 /bin/cygregex.dll 42 /bin/cygssl.dll200 /bin/cygtiff3.dll 65 /bin/cygxml2-2.dll 67 /bin/cygxslt-1.dll161 /bin/cygxsltbreakpoint-1.dll 9 /bin/cygz.dll 25 Regards Ralf
time stamp printing for ssp
Hi,
for application debugging I had the need to see the elapsed time for any step in
ssp, so I've added time stamp printing.
$ cvs diff -p ssp.c
Index: ssp.c
===
RCS file: /cvs/src/src/winsup/utils/ssp.c,v
retrieving revision 1.3
diff -u -3 -p -B -p -r1.3 ssp.c
--- ssp.c 27 Feb 2002 16:10:17 - 1.3
+++ ssp.c 30 Apr 2002 15:30:23 -
@@ -20,6 +20,7 @@
#include time.h
#include ctype.h
#include windows.h
+#include sys/time.h
#ifdef __GNUC__
const char *help_text = \
@@ -326,6 +327,8 @@ run_program (char *cmdline)
int tix, i;
HANDLE hThread;
char *string;
+ long long int starttime,ctime;
+ struct timeval time;
memset (startup, 0, sizeof (startup));
startup.cb = sizeof (startup);
@@ -376,6 +379,13 @@ run_program (char *cmdline)
}
}
+ if (verbose)
+ {
+/* init timecounter */
+gettimeofday(time,NULL);
+starttime = time.tv_sec * 100 + time.tv_usec;
+ }
+
running = 1;
while (running)
{
@@ -407,10 +417,24 @@ run_program (char *cmdline)
printf (\n);
#endif
+if (verbose) {
+ /* print current time */
+ gettimeofday(time,NULL);
+ ctime = time.tv_sec * 100 + time.tv_usec - starttime;
+ {
+ int min = (int) (ctime /6000);
+ int sec = (int) (ctime /100);
+ int millisec = (int) ((ctime /1000) %1000);
+ printf(%02d:%02d.%03d ,min,sec,millisec);
+ }
+ }
+
switch (event.dwDebugEventCode)
{
case CREATE_PROCESS_DEBUG_EVENT:
+ if (verbose)
+ printf(create process at
%08x\n,event.u.CreateProcessInfo.lpStartAddress);
break;
case CREATE_THREAD_DEBUG_EVENT:
@@ -653,6 +677,10 @@ run_program (char *cmdline)
running = 0;
break;
+
+ default:
+ if (verbose)
+printf(unknown event\n);
}
set_steps ();
-
2002-04-30 Ralf Habacker [EMAIL PROTECTED]
* ssp.c (run_program): Added time stamp printing in verbose mode.
Regards
Ralf
RE: ordinal linking for cygwin ld
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
RE: ordinal linking for cygwin ld
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 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 anyone have got experience in such binding stuff ? Ralf
RE: ordinal linking for cygwin ld
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 anyone have got experience in such binding stuff ? No, but perhaps it's the auto-import duplicates that cause the problem? No. I have checked this by a dll without vars. See below: The Import Tables (interpreted .idata section contents) vma:HintTime Forward DLL First Table Stamp ChainName Thunk 4000 4054 420c 4074 DLL Name: dll.dll vma: Hint/Ord Member-Name 40dc0 printfunc__1Av 40f41 printfunc0001__1Av 410c2 printfunc0002__1Av 41243 printfunc0003__1Av 413c4 printfunc0004__1Av 4014 4070 4230 40a8 DLL Name: cygwin1.dll vma: Hint/Ord Member-Name 4154 26 __main 4160 581 calloc 416c 634 cygwin_internal 4180 652 dll_crt0__FP11per_process 419c 722 free 41a4 876 malloc 41b0 1006 realloc The Import Address Table is identical 4028 4094 4248 40cc DLL Name: KERNEL32.dll vma: Hint/Ord Member-Name 41bc 248 GetCurrentProcess 41d0 296 GetModuleHandleA 41e4 661 TerminateProcess The Import Address Table is identical -- rebinding client.exe -- rebind client.exe ./ rebind - message: client.exe dll.dll Module import is starting. rebind - message: client.exe dll.dll Procedure import is starting. printfunc__1Av rebind - message: client.exe dll.dll Procedure import failed. printfunc__1Av He has patched, which you can see below, but break after this. rebind - message: client.exe cygwin1.dll Module import failed. - not found. okay rebind - message: client.exe KERNEL32.dll Module import failed. - not found. okay rebind - message: client.exe (null) Image modified. BIND: Details of binding client.exe Import from dll.dll [6] ^ Import from cygwin1.dll [0] Import from KERNEL32.dll [0] rebind 2 -- The Import Tables (interpreted .idata section contents) vma:HintTime Forward DLL First Table Stamp ChainName Thunk 4000 4054 420c 0004074 DLL Name: dll.dll vma: Hint/Ord Member-Name 40dc0 printfunc__1Av 0001 40f41 printfunc0001__1Av 0004 410c2 printfunc0002__1Av 41243 printfunc0003__1Av 8000 413c4 printfunc0004__1Av 0400 -- rebinding cygwin1.dll -- $ rebind ./client.exe /bin rebind client.exe c:\programme\cygwin\bin rebind - message: client.exe dll.dll Module import is starting. rebind - message: client.exe dll.dll Procedure import is starting. printfunc__1Av rebind - message: client.exe dll.dll Procedure import failed. printfunc__1Av rebind - message: client.exe cygwin1.dll Module import is starting. rebind - message: client.exe c:\programme\cygwin\bin\cygwin1.dll Procedure import is starting. __main rebind - message: client.exe c:\programme\cygwin\bin\cygwin1.dll Procedure import failed. __main rebind - message: client.exe KERNEL32.dll Module import failed. rebind - message: client.exe (null) Image modified. BIND: Details of binding client.exe Import from dll.dll [6] Import from cygwin1.dll [6] Import from KERNEL32.dll [0] -- 4014 4070 4230 40a8 DLL Name: cygwin1.dll vma: Hint/Ord Member-Name 4154 26 __main 61004308 4160 581 calloc 416c 634 cygwin_internal 4180 652 dll_crt0__FP11per_process 419c 722 free 41a4 876 malloc 41b0 1006 realloc -- ^^ Do you see this ? The first is set correct, the other set to zero. The masin difference I see currently
RE: ordinal linking for cygwin ld
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 - and lots of fixups needed. Yes, these are the costs.
RE: ordinal linking for cygwin ld
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 linking and allow limiting of used libs or path for example --enable-ordinal-link[=path1[,path2]] enable ordinal linking for given path/files or unlimited ordinal linking if no path is given. --disable-ordinal-link[=path1[,path2]] disable ordinal linking for the following path/files Ralf
RE: ordinal linking for cygwin ld
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 though, as that would a) give the performance benefit you are looking for b) allow backward compatible library versioning as link-by-name does. We'd probably also need to ensure that strip leaves the names in the IAT (I wasn't clear from your other email whether it does that or not). Yes it does. See some parts about my auto-import documentation. $ objdump -x client.exe snip The Import Tables (interpreted .idata section contents) vma:HintTime Forward DLL First Table Stamp ChainName Thunk (1) 4000 4068 41a8 40b4 |(3) |(2) |_nm_ (4)IAT | _imp_... +--++++--+ | (6)+| Hint 16bit |(7)-- | +--+ | +++--+ | | | | membername |(8) +--+ +--+ | +++--+ | +--+ | _nm_... (5) +--+ | +-+ +--+ +|Ordinal 16bit|(7)+--+ +-+ | 0x00 0x80 | +-+ (1) is the IMAGE_IMPORT_DESCRIPTOR. FirstThunk (2) points to the import address table (IAT), which entries are identifed by corresponding _imp_... symbols. HintTab (3) point to a rva (relative virtual address = offset from image start) vector pointing to IMAGE_IMPORT_BY_NAME unions. (4) shows an IMAGE_IMPORT_BY_NAME union for a named link. It is identifed by the _nm_smbol name . In this structure the symbol name string is stored independed from the regular symbol name, which can be only stripped. (5) shows a IMAGE_IMPORT_BY_NAME union for a ordinal link. Now see the relating objdump part. The numbers 6,7,8 identify the related structure element. DLL Name: dll.dll vma: Hint/Ord Member-Name (6) (7) (8) 40f40 printfunc__1Av 410c1 var 00404290 __nm__var: 404290: 01 00 404292: 76 61 404294: 72 30 404296: 30 30 404298: 30 00 No see this for an auto-imported data vma:HintTime Forward DLL First Table Stamp ChainName Thunk 4000 4068 41a8 1064 |(3) |(2) nm_thnk_... _nm_... (4)| +--+++__fu0_... | (6)+| Hint 16bit |(7) points directly into the text segement +--+ | ++to the relating instructions address | | | | Membername |(8) +--+ | ++ | | _nm_... (5) | +-+ +|Ordinal 16bit|(7) +-+ | 0x00 0x80 | +-+ It's the same as above except (2) points directly into the text segement to the relating instructions address. The target is identified by the __fu0_symbol name. See a sample below. 0xa1 is the instruction at offset 0x401063, the address starts at 0x0401063. 401063: a1 b8 40 40 00 mov0x4040b8,%eax ^^^ 00401064 __fu0__var: ^^ (3) HintTab is identifed by the _nm_thnk_symbol. 004040a8 __nm_thnk__var: 4040a8: 02 00 4040aa: 00 80 00 00 00 00 Hope that helps Ralf
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
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, without relinking? Because the patch does only affect generating import library, this condition is obsolate. A real test is relinking the app with an unmodified ld. I'll send a testcase protocol in the near furture. Regards Ralf
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
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 -
/usr/bin/as.exe
lrwxrwxrwx1 1002 Kein 26 Apr 19 07:49 ld.exe -
/usr/bin/ld.exe
lrwxrwxrwx1 1002 Kein 26 Apr 19 07:49 nm.exe -
/usr/bin/nm.exe
lrwxrwxrwx1 1002 Kein 30 Apr 19 07:49 ranlib.exe -
/usr/bin/ranlib.exe
lrwxrwxrwx1 1002 Kein 29 Apr 19 07:49 strip.exe -
/usr/bin/strip.exe
$ cp /bin/ld.exe.2006 /bin/ld.exe
$ ld -v --help | head -1
GNU ld version 2.11.92 20011216
$ cat dll.cc
#include stdio.h
int var=0;
namespace A {
void printfunc(void){ printf(printfunc%04d called\n,0); }
}
$ cat dll.h
extern int var;
namespace A {
void printfunc(void);
}
#define vars() \
printf(v=%04d\n,var);\
#define funcs() \
A::printfunc();\
$ make dll.dll
gawk -f dll.awk dll.cc
g++ -c -o dll.o dll.cc
g++ --shared dll.o -o dll.dll -Wl,--out-implib,libdll.a
Creating library file: libdll.a
$ nm libdll.a
d11.o:
i .idata$4
i .idata$5
i .idata$7
I _dll_dll_iname
d00.o:
i .idata$2
i .idata$4
i .idata$5
I __head_dll_dll
U _dll_dll_iname
d10.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp__var
I __nm__var
d09.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp__printfunc__1Av
I __nm__printfunc__1Av
T _printfunc__1Av
d08.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp___nm__realloc
I __nm___nm__realloc
d07.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp___nm__printf
I __nm___nm__printf
d06.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp___nm__malloc
I __nm___nm__malloc
d05.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp___nm__free
I __nm___nm__free
d04.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp___nm__dll_dllcrt0
I __nm___nm__dll_dllcrt0
d03.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp___nm__cygwin_internal
I __nm___nm__cygwin_internal
d02.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp___nm__cygwin_detach_dll
I __nm___nm__cygwin_detach_dll
d01.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp___nm__calloc
I __nm___nm__calloc
done
b) build an app that uses that dll, and which accesses both a function
export and a data export from the dll.
$ cat client.cc
#include stdio.h
#include dll.h
main()
{
funcs();
vars();
}
$ make client.exe
g++ -c -o client.o client.cc
g++ -o client.exe client.o -v -Wl,--enable-auto-import -L. -ldll
Warning: resolving _var by linking to __imp__var (auto-import)
$ ./client.exe
printfunc called
v=
c) rebuild the dll using your modified ld.
cp ~/src/sources.redhat.com/src/ld/ld-new /bin/ld.exe
$ ld -v --help | head -1
GNU ld version 2.12.90 20020425
$ rm dll.dll
habacker@BRAMSCHE ~/src/ld-contrib/ld-bugfix-test
$ make dll.dll
g++ --shared dll.o -o dll.dll -Wl,--out-implib,libdll.a
Creating library file: libdll.a
to verify that the patch does his work, compare with mentioned above nm list.
$ nm libdll.a
d03.o:
i .idata$4
i .idata$5
i .idata$7
I _dll_dll_iname
d00.o:
i .idata$2
i .idata$4
i .idata$5
I __head_dll_dll
U _dll_dll_iname
d02.o:
i .idata$4
i .idata$5
i
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
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 wrote:
b) build an app that uses that dll, and which accesses both a function
export and a data export from the dll.
$ cat client.cc
#include stdio.h
#include dll.h
main()
{
funcs();
vars();
}
Except that I'd access 'v' *directly* from client.cc; you're not
*really* accessing the variable yourself; you're calling a function in
the DLL which accesses the variable.
... and accessing var in client.cc
Do you have really read the dll.h ?
snip
#define vars() \
printf(v=%04d\n,var);\
snip ^^^
the vars macro is called in client.cc !!
Ralf
RE: ordinal linking for cygwin ld
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 linking and allow limiting of used libs or path Hangon, lets go back a bit. Why do you want ordinal-only linking? For runtime or link-time performance? Or for on-disk import library size? Or runtime performance Rob
ordinal linking for cygwin ld
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 the influence of symbol name to the runtime linking time. So I have build a dll 5000 functions and a client app, which uses this functions. This dll/apps are compiled in two variants, 1. with a symbolname lenght of a 13 characters and 2. with a symbolname lenght of 403 characters (should simulate long c++ names). cd shortname time ./client.exe real0m0.772s user0m0.030s sys 0m0.030s $ cd longname $ time ./client.exe real0m15.182s user0m0.060s sys 0m0.040s The result shows that this has a great effect of app/dll loading time (about 20 times more). After thinking a while about this, I remembered, that the windows pe format allows two runtime linking types. The first, usually used, is linking by the symbol name, the second is linking by symbols ordinal. A look in the last official cygwin ld (20011002) source shows, that linking by ordinal seems to be prepared with one limitation. There is no command line switch to create an import library for ordinal linking on dll building, so I've added a switch --out-implib-ordinal filename. (BTW: Another possibibily was automatic ordinal linking. See later) Now I've tried a second test. 5000 functions with symbolname lenght of 403 characters linked 1. with names and 2. with ordinals. 5000 functions with symbol name linking (symbols not stripped) $ time ./client.exe real0m15.182s user0m0.060s sys 0m0.040s 5000 functions with ordinal linking (symbols not stripped) $ time ./client.exe real0m0.572s user0m0.020s sys 0m0.030s Wow, thats great. 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) 2. Another possibility is using the regular import libraries hint number for ordinal linking (hint number = Ordinal number-1), but currently I don't know if this is always true. Solution 1 has an advantage on building big c++ libs, because the import library are smaller (about 20-50%). See the following example. The amount depends on the symbols count and length. old -rwxr-xr-x1 1002 Kein 1682944 Apr 22 09:42 /opt/kde2/bin/cygkdecore-3.dll -rwxr-xr-x1 1002 Kein 3190016 Apr 20 19:12 /opt/kde2/lib/libkdecore.dll.a new -rwxrwxrwx1 1002 Kein 1956812 Apr 26 22:03 libkdecore.dll.a -rwxrwxrwx1 1002 Kein 1608192 Apr 26 22:28 cygkdecore-3.dll Solution 2 is full compatible to dll's builded with previous ld, because the dll and import lib are still the same. Compiling an app with new ld will automatically use ordinal linking. The only necessary point seems to me a command line switch to switch of this behavior. Any comments ? Regards Ralf ld_ordinal_linking_2.patch Description: Binary data ld_ordinal_linking_testcase.tar.bz2 Description: Binary data
RE: ordinal linking for cygwin ld
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 one undefinded var im pe.em, which is fixed with the current patch. Sorry Regards Ralf ld_ordinal_linking_3.patch Description: Binary data
RE: ordinal linking for cygwin ld
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 the DLL with an additional data export. Since no interface elements have been changed or removed, only added, your app SHOULD be compatible with this DLL. But, if the vendor isn't careful, the new DLL could end up like this: func_one 1 var_two DATA 2 func_two 3 var_one DATA 4 Since your app linked by ordinal, it will break if you try to run it with the new DLL, without re-linking. accepted So how does the vendor ensure that he doesn't unnecessarily break backwards compatibility, and keep the ordinals the same? By using a def file. Or be relinking all the libs. There's one big problem with that: def file are a !#@^% to maintain. You *always* forget to add something -- upstream maintainers are absolutely horrible about NOT documenting all of the new functions/data exports that they add. So you end up building the DLL with auto-export, use objdump to list the exports, sort 'em, eliminate against your old .def file, create a new .def file It's just a PITA. And one time, back when I was using .def files, I actually managed, even with all of that effort, to release a DLL that dropped one of the exports the OLD dll had, and broke everybody's app. And I only deal with about 20 packages and DLLs. I shudder to think of maintaining all of that for the 200-odd DLLs that come with KDE. Using def files is unusable. Then, there's one smaller problem: 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 _imp_symbol was found, that means from the client side. There was no access (except of the dll name) to the implibs data. not the symbol ordinal... I have patched auto-import stuff which got the ordinal from the implib. It works with the appended testcase. Currently I've build a new working qt with this. IMO, the better solution is to provide a pre-load app, to load all of the core KDE dlls into memory at bootup. This is what Netscape/Mozilla now do, and what MS has been doing with IE for years: hide the load time during the bootup sequence; at least that way, KDE/Moz/Ntsp/IE doesn't get the blame... In the second solution I have told about, using the regular implibs and decide on a per case base if ordinal linking or not. 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. Second some dll's are only for specific apps for example konqueror or kcontrol, which holds there code in some dll's. When rebuilding konqueror the dll's could be linked ordinal without any problems, because there were all rebuild. Ralf --Chuck
RE: ordinal linking for cygwin ld
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 the second solution I have told, normal import library and using a special linker switch for using ordinal linking. Ralf
RE: ordinal linking for cygwin ld
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 _imp_symbol was found, that means from the client side. There was no access (except of the dll name) to the implibs data. Of course are the sections of the implib imported in the resulting binary, but currently I have an idea, how to save additional space in the implib. (for example the qt2.3.1 implib is about 8MB and contains 12079 symbols) At least each symbol name exist twice. Perhaps this can be put together d012073.o: i .idata$4 i .idata$5 i .idata$6 i .idata$7 t .text U __head_qt_2_3_dll (a) I __imp__y__C13QIconViewItem (b) T _y__C13QIconViewItem -(a) __imp__y__C13QIconViewItem ^ (b) points to (a) + offset If this is possible there is no space need to build a import lib without names, because it will be a little about the half of the current size. I will see. Regards Ralf
RE: ordinal linking for cygwin ld
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 broken because you released new compatible libs. Not good -- and it'd take a while to track the problem down too: (a) I need to relink my dll, and give it to Bob, and then (and only then) (b) Bob can relink his app. Blech. Wait for the rules in my next mail. I shudder to think of maintaining all of that for the 200-odd DLLs that come with KDE. Using def files is unusable. Unless it's the only way to avoid the problems above. Then, you ignore the pain and just do it -- or write code to do it for you, like the openoffice guys have done. Then, there's one smaller problem: 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 _imp_symbol was found, that means from the client side. There was no access (except of the dll name) to the implibs data. Okay... not the symbol ordinal... I have patched auto-import stuff which got the ordinal from the implib. It works with the appended testcase. Currently I've build a new working qt with this. In the second solution I have told about, using the regular implibs and decide on a per case base if ordinal linking or not. 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. Ah, so there'd be a special switch that KDE's internal makefiles use to turn on 'link by ordinal' behavior; other applications would not use it, and would thus link by name? (or, they'd use it and link-by-ordinal at their own risk...) That seems workable to me. Second some dll's are only for specific apps for example konqueror or kcontrol, which holds there code in some dll's. When rebuilding konqueror the dll's could be linked ordinal without any problems, because there were all rebuild. Errr...not so fast. Code reuse -- konqueror dlls can be linked into other apps, can't they? -- or is all code reuse of that nature in KDE done via KParts/Bonobo/CORBA/whatever, and not actual linking? We will have to look at this a little deeper. Ralf
RE: ordinal linking for cygwin ld
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 other mails from me)
RE: ordinal linking for cygwin ld
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
RE: ordinal linking for cygwin ld
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 ? Now, I'm going to bed, it is 2:43am in germany. God night. Ralf
cygwin ld import library issue fix (removing unused _nm_ symbols)
Hi,
this patch fixes an cygwin ld issue (GNU ld version 2.11.92 20011001) I've
encountered while analysing the runtime linking performance for kde.
Background:
The ld-auto-import stuff introduces additional symbols (_nm_...) in the import
library which are only needed for data exports.
Unfortunally this symbols are generated for every export.
Additional ld rexports imported _nm_ symbols from other dlls, so one get
symbols like _nm___nm__scanf for example.
One can say this isn't a real problem and the answer is yes ... for little
dll's.
But if you look in the below mentioned import libraries, one can save about 30%
of the import libraries size.
For the kde 2.2.2 devel libs and base package this would save about 26MB.
And this seems to be a fact for applying this fix.
without patch
-rwxrwxrwx1 1002 Kein 3190016 Apr 20 19:12 libkdecore.dll.a
-rwxrwxrwx1 1002 Kein 7526 Apr 20 19:01 libkdefakes.dll.a
-rwxrwxrwx1 1002 Kein 5693370 Apr 20 01:16 libkdeui.dll.a
with patch
-rwxrwxrwx1 1002 Kein 2126660 Apr 25 10:48 libkdecore.dll.a
-rwxrwxrwx1 1002 Kein 1448 Apr 25 10:45 libkdefakes.dll.a
-rwxrwxrwx1 1002 Kein 3622512 Apr 25 11:06 libkdeui.dll.a
$ diff pe-dll.c.orig pe-dll.c -ubBp
--- pe-dll.c.orig Wed Apr 24 09:48:59 2002
+++ pe-dll.cThu Apr 25 08:33:08 2002
-248,6 +250,8 static autofilter_entry_type autofilter_
/* Do __imp_ explicitly to save time. */
{ __rtti_, 7 },
{ __builtin_, 10 },
+ // RH: prevent generating reimported functions
+ { _nm_, 4 },
/* Don't export symbols specifying internal DLL layout. */
{ _head_, 6 },
{ _fmode, 6 },
-1789,6 +1793,8 make_one (exp, parent)
quick_symbol (abfd, U (_imp__), exp-internal_name, , id5, BSF_GLOBAL,
0);
/* Symbol to reference ord/name of imported
symbol, used to implement auto-import. */
+ /* RH: only for auto-imported data */
+ if (exp-flag_data)
quick_symbol (abfd, U(_nm__), exp-internal_name, , id6, BSF_GLOBAL, 0);
if (pe_dll_compat_implib)
quick_symbol (abfd, U (__imp_), exp-internal_name, ,
Any comments ?
Regards
Ralf Habacker
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
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 that means cygwin support seems to be broken. Because I hadn't enough time to check this, I installed the sources from the last official cygwin binutils release (GNU ld version 2.11.92 20011001) and have applied this patch. Ralf
patch for objdump/cygwin crashes on auto-imported libs bug
Hi all,
currently I'm working on an ordinal linking option for ld (performance benefits
for the kde-port) and have analysed the auto-import internals. While doing this
I got the knowledge to fix the bug
described in http://sources.redhat.com/ml/binutils/2002-01/msg00093.html.
$ diff -ubBp bfd/peigen.c.org bfd/peigen.c
--- bfd/peigen.c.orgThu Apr 25 15:37:26 2002
+++ bfd/peigen.cThu Apr 25 15:57:50 2002
@@ -1226,7 +1226,15 @@ pe_print_idata (abfd, vfile)
idx2 = first_thunk - adj;
- for (j = 0; j datasize; j += 4)
+ /* indicates that first_thunk points to an
+ data reference in the text segment (auto-import) */
+ if (idx2 0)
+{
+ fprintf (file,
+_(\tThe Import Address Table isn't identical (auto-import
descriptor)\n));
+differ = 1;
+ }
+ else for (j = 0; j 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-descriptors
Any comments ?
Ralf
RE: patch for objdump/cygwin crashes on auto-imported libs bug
-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 of this topic. At first the basics are
described in http://msdn.microsoft.com/msdnmag/issues/02/03/PE2/PE2.asp. See
the chapter The import sections
Normally the image_import_descriptor and the Image Adress Table (IAT) identifed
by first_thunk are located behind the text segment and idx2 is positive.
On a auto-import image descriptor the main difference is, that the first_thunk
does not point to the import address table (IAT), instead it points to an adress
in the text segment where the opcode reads or write the (auto-imported) data
values. This let idx2 be negative, which I have used for decision.
pe_print_idata (abfd, vfile)
snip
adj = section-vma - extra-ImageBase;
0x0040
snip
hint_addr = bfd_get_32 (abfd, data + i + dataoff);
time_stamp = bfd_get_32 (abfd, data + i + 4 + dataoff);
forward_chain = bfd_get_32 (abfd, data + i + 8 + dataoff);
dll_name = bfd_get_32 (abfd, data + i + 12 + dataoff);
first_thunk = bfd_get_32 (abfd, data + i + 16 + dataoff);
snip
if (hint_addr != first_thunk time_stamp == 0)
{
int differ = 0;
int idx2;
idx2 = first_thunk - adj;
/* indicates that first_thunk points to an
data reference in the text segment (auto-import) */
if (idx2 0)
{
fprintf (file,
_(\tThe Import Address Table isn't identical (auto-import
descriptor)\n));
differ = 1;
}
else for (j = 0; j datasize; j += 4)
Regards
Ralf
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
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 export
reimported functions.
(make_one): let create only _nm_.. for data symbols
Index: pe-dll.c
===
RCS file: /cvs/src/src/ld/pe-dll.c,v
retrieving revision 1.38
diff -u -3 -p -r1.38 pe-dll.c
--- pe-dll.c15 Feb 2002 02:11:05 - 1.38
+++ pe-dll.c25 Apr 2002 18:34:43 -
@@ -252,6 +252,8 @@ static autofilter_entry_type autofilter_
/* { __imp_, 6 }, */
/* Do __imp_ explicitly to save time. */
{ __rtti_, 7 },
+ /* Don't export reimported functions*/
+ { _nm_, 4 },
{ __builtin_, 10 },
/* Don't export symbols specifying internal DLL layout. */
{ _head_, 6 },
@@ -1793,8 +1795,11 @@ make_one (exp, parent)
quick_symbol (abfd, U (_head_), dll_symname, , UNDSEC, BSF_GLOBAL, 0);
quick_symbol (abfd, U (_imp__), exp-internal_name, , id5, BSF_GLOBAL,
0);
/* Symbol to reference ord/name of imported
- symbol, used to implement auto-import. */
- quick_symbol (abfd, U(_nm__), exp-internal_name, , id6, BSF_GLOBAL, 0);
+ symbol, used to implement auto-import.
+ (only for data symbols) */
+ if (exp-flag_data)
+quick_symbol (abfd, U(_nm__), exp-internal_name, , id6, BSF_GLOBAL,
0);
+
if (pe_dll_compat_implib)
quick_symbol (abfd, U (__imp_), exp-internal_name, ,
id5, BSF_GLOBAL, 0);
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
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 sources.redhat.com. It produces undefined symbols compiling dll/apps and that means cygwin support seems to be broken. Because I hadn't enough time to check this, I've taken a look on the cvs archive to verify this. Are I'm right using the cygnus_cvs_20020108_pre tag ? Why are you using a tag at all? Your patches should be against the binutils trunk. I have updated the patch. But the problem still is as I've said. The current ld cvs head release does not work !! I have build a simple lib and an app (without my patches) and the result is an undefined, either for functions or for auto-imported data. Test case is appended. 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. $ make dll.dll client.exe gawk -f dll.awk dll.cc g++ -c -o dll.o dll.cc g++ --shared dll.o -o dll.dll -Wl,--out-implib,libdll.a Creating library file: libdll.a g++ -c -o client.o client.cc g++ -o client.exe client.o -v -Wl,--enable-auto-import -L. -ldll #-ldll2 Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specs gcc version 2.95.3-5 (cygwin special) /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/collect2.exe -Bdynamic --dll-search-pre fix=cyg -o client.exe /usr/lib/crt0.o - L. -L/usr/local/lib -L/usr/lib -L/usr/lib/w32api -L/usr/lib/gcc-lib/i686-pc-cygw in/2.95.3-5 -L/usr/lib/gcc-lib/i686-pc-c ygwin/2.95.3-5/../../../../i686-pc-cygwin/lib client.o --enable-auto-import -ldll -lstdc++ -lgcc -lcygwin -luser32 -lker nel32 -ladvapi32 -lshell32 -lgcc client.o(.text+0x48):client.cc: undefined reference to `A::printfunc(void)' client.o(.text+0x4d):client.cc: undefined reference to `A::printfunc0001(void)' client.o(.text+0x52):client.cc: undefined reference to `A::printfunc0002(void)' client.o(.text+0x57):client.cc: undefined reference to `A::printfunc0003(void)' client.o(.text+0x5c):client.cc: undefined reference to `A::printfunc0004(void)' client.o(.text+0x64):client.cc: undefined reference to `var' client.o(.text+0x7a):client.cc: undefined reference to `var0001' client.o(.text+0x90):client.cc: undefined reference to `var0002' client.o(.text+0xa6):client.cc: undefined reference to `var0003' client.o(.text+0xbc):client.cc: undefined reference to `var0004' collect2: ld returned 1 exit status make: *** [client.exe] Error 1 client.tar.bz2 Description: Binary data
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
* 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 are
located in the bfd lib
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/ld/emultempl/pe.em?rev=1.57con
tent-type=text/x-cvsweb-markupcvsroot=src
Revision 1.57 / (download) - annotate - [select for diffs] , Mon Dec 17 00:40:53
2001 UTC (4 months, 1 week ago) by amodra
Branch: MAIN
Changes since 1.56: +4 -0 lines
Diff to previous 1.56 (colored)
hash bfd sections for fast lookup and create.
bfd/ChangeLog
* bfd.c (struct _bfd): Add section_htab, section_tail.
* libbfd-in.h (_bfd_delete_bfd): Declare.
(bfd_section_hash_newfunc): Declare.
* opncls.c (_bfd_new_bfd): Free memory on failure. Init
section_htab and section_tail.
(_bfd_delete_bfd): New function.
(bfd_openr): Use it.
(bfd_fdopenr): Likewise.
(bfd_openstreamr): Likewise.
(bfd_openw): Likewise.
(bfd_close): Likewise.
(bfd_close_all_done): Likewise.
(bfd_release): Comment.
* section.c (struct section_hash_entry): New.
(bfd_section_hash_newfunc): New function.
(section_hash_lookup): Define.
(bfd_section_init): New function, split out from
bfd_make_section_anyway.
(bfd_get_section_by_name): Lookup via hash table.
(bfd_get_unique_section_name): Likewise.
(bfd_make_section_old_way): Rewrite to use hash table.
(bfd_make_section_anyway): Likewise.
(bfd_make_section): Likewise. Return NULL for attempts to make
BFD_{ABS,COM,UND,IND}_SECTION_NAME.
(_bfd_strip_section_from_output): Adjust section_tail if needed.
* configure.in: Bump bfd version.
* configure: Regenerate.
* libbfd.h: Regenerate.
* bfd-in2.h: Regenerate.
ld/ChangeLog
* emultempl/elf32.em (gld${EMULATION_NAME}_place_orphan): Adjust
section_tail when fiddling with section list.
(gld${EMULATION_NAME}_list_options): Ensure sentences aren't
broken into separate strings to make translation easier.
* emultempl/mmo.em (mmo_place_orphan): Adjust section_tail when
fiddling with section list.
* emultempl/pe.em (gld_${EMULATION_NAME}_place_orphan): Likewise.
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
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
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
--- 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). So it seems to me, that the last official binutils release was the last stable release. Has noone checked the patches after the last official release ? Ralf 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. Your right, I have compared the implib and in 3,4,7,8 (see below) the symtable is missing. funcs linking dll app 1 old old - no problems 2 old new - no problems 3 new old - undefined reference error 4 new new - undefined reference error auto-imported data linking dll app 5 old old - no problems 6 old new - BFD 2.12.90 20020425 internal error, 7 new old - undefined reference error 8 new new - undefined reference error
RE: FW: libtool devel package still dll crippled.
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 implementation of libc. Of course when this happens inadvertently it can lead to unexpected behaviour/crashes. ELF (The linking format used on Linux) has rather complex rules for determining which symbol should be used if it is defined multiple times. It also distinguishes between weak and strong symbols. It might be that it is only possible to override weak-symbols and that multiple strong-symbols result in link-errors. Does the cygwin ld has some similar rules ? Is nobody on this list, who can give an answer to this question ? Ralf
RE: FW: libtool devel package still dll crippled.
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 if someone build a second dll with the same static lib, the symbols of the static libs are in both shared lib defined. Then if someone uses these two shared libs to build for example an application, ld fails with duplicated symbol errors. How does ld prevent this ? 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 implementation of libc. Of course when this happens inadvertently it can lead to unexpected behaviour/crashes. ELF (The linking format used on Linux) has rather complex rules for determining which symbol should be used if it is defined multiple times. It also distinguishes between weak and strong symbols. It might be that it is only possible to override weak-symbols and that multiple strong-symbols result in link-errors. Does the cygwin ld has some similar rules ?
RE: libtool devel package still dll crippled.
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 --exclude-libs=* or something else 2c) identify the libs not to export and set an option like --exclude-libs=lib1,lib2, Sorry, Ralf
RE: libtool devel package still dll crippled.
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 always_export_symbols settings now and send another email when that build is done. I think we should leave the always_export_symbols as yes, but I'm not religious. Ralf, whats the reason to change that to no? I get better results with it set to yes, which is why I am asking.. I had recgonized problems with the allow_undefined_flag=unsupported and have tried only with no, which works. Yet I have tried with yes it works too. So its no problem for me to use yes. _LT_AC_TAGVAR(always_export_symbols, $1)=yes Using yes causes libtool to use nm to generate a symbol list, which is avoided by setting to no. /usr/local/bin/nm -B .libs/profiler.o | sed -n -e *[ ]\([ABCDGISTW][ABCDGISTW]*\)[ ][ ]*\(_\)\([_A- Za-z][_A-Za-z0-9]*\)$/\ 1 \2\3 \3/p' | sed 's/.* //' | sort | uniq .libs/libprofiler.exp In small projects this may be no difference, but if you have to build hundrets of dll's with thousands of symbols this makes a difference in linking time. Does the cygwin ld really need this way of creating symbol lists ? Ralf
RE: libtool devel package still dll crippled.
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 autofilter_liblist[] =
{
{ libgcc., 7 },
{ libstdc++., 10 },
{ libmingw32., 11 },
+// RH: workaround to allow using static libs
in multiple
dlls
+ { .a, 2 },
{ NULL, 0 }
};
I really think this is a mistake. What if I want
to build a shared
library using libtool, and it is composed of a
number of object files
but also some convenience libs? And those
convenience libs contains
symbols that I want to export?
I have not said, that this workaround is a general patch
usable
in all situations. Because KDE does create only dll's this
was okay for me.
Dannys patch is of course the beest solution, but it
requires
some (as I recognized after reviews this patch) deeply
changes of the
libtool implementation, which isn't not easy. :-(
Ralf
RE: DocBook and OpenJade packages
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 was quite fiddly, as there are many small tools that have to be downloaded and configured. I'm willing to volunteer to produce and maintain proper CygWin packages for these tools, so that they can be easily installed by just choosing the packages in the setup program. * Is this something you'd like? for the kde2.2.x port too. This would be nice for kdevelop, which need this * Is anybody currently working on this? I have tried to compile Openjade, but without success. So I have stopped this. As per the guidelines at http://cygwin.com/setup.html, I've written proposed setup.hint files - they're at the end of this e-mail. Comments welcome. I haven't started working on the actual packages yet. Kind regards, Jon Foster --- sgml-base/setup.hint --- # This package is assembled from: # - A perl script to maintain the SGML catalog file, probably from Debian's # sgml-base package, and probably modified for cygwin - I haven't checked # yet. # - ISO entity definitions, from http://www.oasis-open.org/cover/ISOEnts.zip # - HTML 3.2 DTDs from http://www.w3.org/TR/REC-html32 # - HTML 4.0 DTDs from http://www.w3.org/TR/1998/REC-html40-19980424 # - HTML 4.01 DTDs from http://www.w3.org/TR/1999/REC-html401-19991224 # category: Text requires: perl bash # perl - To run the SGML catalog maintainace script. # bash - To run the post-install script to set up an SGML catalog. test: 1.01-1 sdesc: A basic SGML tree, and tools to maintain it. ldesc: A basic SGML tree, and tools to maintain it. Includes the ISO entities, and the definitions of HTML 3.2, 4.0 and 4.01. --- openjade/setup.hint --- # Original source: http://openjade.sourceforge.net/ category: Text requires: cygwin sgml-base bash # cygwin- This package contains binaries. # sgml-base - So we can add DTDs to the SGML catalog. # bash - To run the post-install script to update the SGML catalog. test: 1.3.1-1 sdesc: The OpenSP SGML parser and the OpenJade DSSSL processor. ldesc: The OpenSP SGML parser and the OpenJade DSSSL processor. OpenSP is a library for reading SGML files. OpenJade can transform SGML files into other formats, such as HTML and TeX files. The transformation is controlled by DSSSL style sheets (not included). OpenJade is commonly used with the docbook and docbook-dsssl packages. For more information, see http://openjade.sourceforge.net/; --- xhtml-dtd/setup.hint --- # Original sources: # XHTML 1.0 DTD: http://www.w3.org/TR/xhtml1/ # XHTML 1.1 DTD: http://www.w3.org/TR/xhtml11/ # # (This package is included for completeness, not because DocBook needs it). # category: Text requires: sgml-base libxml2 bash # sgml-base - So we can add DTDs to the SGML catalog. # libxml2 - So we can add DTDs to the XML catalog. # bash - To run the post-install script to update the SGML # and XML catalogs. test: 1.1-1 sdesc: DTDs defining XHTML 1.0 and 1.1, for use by XML and SGML tools. ldesc: DTDs defining XHTML 1.0 and 1.1, for use by XML and SGML tools. For more information, see http://www.w3.org/MarkUp/; --- docbook/setup.hint --- # Original source: http://www.oasis-open.org/docbook/ category: Text requires: sgml-base openjade bash # sgml-base - So we can add DTDs to the SGML catalog. # bash - To run the post-install script to update the SGML catalog. # openjade - not really required for installation, but if you # want to do anything *useful* with it you'll need an # SGML parser, and openjade is the only one cygwin offers. test: 4.1-1 sdesc: An SGML DTD for writing books and other documentation. ldesc: An SGML DTD for writing books and other documentation, especially technical documentation. To convert DocBook documents to other formats such as HTML, you also need the package docbook-dsssl. This DTD is also available in XML flavour (in package 'docbook-xml'). See http://www.oasis-open.org/docbook/ for more information. --- docbook-xml/setup.hint --- # Original source: http://www.oasis-open.org/docbook/ category: Text requires: sgml-base libxml2 bash # sgml-base - So we can add DTDs to the SGML catalog. # libxml2 - So we can add DTDs to the XML catalog. # bash - To run the post-install script to update the SGML # and XML catalogs. test: 4.1.2-1 sdesc: An XML DTD for writing books and other documentation. ldesc: An XML DTD for writing books and other documentation, especially technical documentation. To convert DocBook documents to other formats such as HTML, you also need the package docbook-xsl. This DTD is also available in SGML flavour (in package 'docbook'). See
RE: libtool-devel and kde2 - problem with AC_PROG_CXX
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). Unfortunately, it can't be easily told apart from 1.4, you'll have to check the version number inside ltmain.sh. For the _last time_, the devel libtool DOES NOT and WILL NOT create ltconfig. Don't expect it, because its NOT MEANT TO create it. It does not create ltconfig, but it need it as you could see in my last mail As of 20010531, there seem to have been a few remaining references to ltconfig -- within the _LT_AC_LANG_CXX and _LT_AC_LANG_GCJ m4 macros. Not surprising that those were missed -- C++/java don't have nearly the history that C does. Studying the ChangeLogs, ltconfig was removed on 2000-09-19, but stale references were continually being found and fixed thru 2001 (2001-04-05, 2001-04-24). Aha checking if libtool supports shared libraries... yes checking how to run the C++ preprocessor... g++ -E admin/ltconfig: Can't open admin/ltconfig: No such file or directory configure: error: libtool tag configuration failed I have searched in the libtool cvs on subversions.gnu.org and seen that on 20010531 the merge of the mlb code wasn't ready. You can verify this by unpacking the recent libtool-devel-20010531-6.tar.bz2 and looking in the libtool.m4 if there are references to ltconfig. Not entirely correct. As I said, it seems that the _CXX and _GCJ references hadn't been removed as of 20010531. However, the MLB merge was -- if not complete, then at least partially begun: 2001-05-27: ltmain.in: Merged from multi-language-branch 2001-05-27: libtool.m4: Merged from multi-language-branch 2001-05-30: libtool.m4: Merged ltconfig.in from multi-language-branch ^^ not a typo However, as you say, there were some ADDITIONAL merges from MLB that happened later: on 2001-06-24. If you follow the below mentioned link you can see that the tag creation support was completed at 2001 Jun 24 , so the libtool from 20010531 can't contain full tag creation support. [snip] I have appended a patched libtool.m4 from the libtool cvs HEAD release numver 1.245 and patched mostly of the changes Charles provided in the rc5 diffs and got a working CXX/GCJ/RC tag creating. Try it. It may not be complete for all cases, but I think you are able to verify this. Actually, I am not able to guarantee that 1) taking the Robert's patches to libtool.m4(20010531) 2) applying those changes to libtool.m4(20011128) 3) but NOT updating any of the other interdependent files that form the libtool toolset results in a stable libtool. You have said that it works well for you on a given set of dlls -- but you've already demonstrated that your case is rather special: multi-language, CXX/GCJ, etc. I don't want to fix the corner case by breaking the mainline cases: single language, C. I understand Look, Ralf, this libtool port is a work in progress. Right now, I'd like for folks to test the normal stuff. (So far, that looks good). Then, we need to port forward ALL of the patches to ALL of the files -- not just libtool.m4 -- to current HEAD cvs libtool. Okay that make sense Gary Vaughan (the libtool maintainer) is on the case, he WANTS to put this stuff into current cvs. He was waiting for Robert's FSF copyright assignment to go thru before he started : and that just happened last week (see the libtool mailing list...) I have seen this on the libtool list Be patient -- it was hard enough getting the infrastructure in place to have an auto-import capable libtool become part of the cygwin dist in the first place. I couldn't very well pester Gary to accept the patches until we had a working example installation...and that just happened last week. I have not problem with this Just to review the tool-side things that have been happening in the past six months (not all me, but I *have* been pushing most of them) test Paul Sokolovsky's auto-import stuff push it into official binutils migrate (old) autoconf package to autoconf-stable create autoconf-devel package (and talk very very fast to get corinna to support it) create autoconf (wrappers) migrate (old) automake package to automake-stable create automake-devel package (and talk very very fast...) create automake (wrappers) special automake hack to make the split-install ALSO search /usr/share/aclocal in addition to /usr/autotool/*/share/aclocal create libtool-stable (1.4.2) create libtool-devel package from Robert's patches (but based on an old version of libtool cvs: 20010531) create libtool-wrappers AND, spread amonst all of those steps, was a lot of advocacy and discussion on the various mailing
RE: problem with make
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher Faylor Sent: Tuesday, December 04, 2001 4:57 PM To: [EMAIL PROTECTED] Subject: Re: problem with make On Tue, Dec 04, 2001 at 08:14:04PM +1100, Robert Collins wrote: - Original 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 (spelling?) flag. The core problem though is that that use they are making of the filesystem is invalid for case insensitive filesystems - and windows isn't the only one around. Also, please use [EMAIL PROTECTED] for this type of bug reporting. This is not an applicable topic for cygwin-apps. From the mailing list page: cygwin-apps: a by-approval developers list for discussing issues regarding applications that are distributed with the Cygwin DLL. Is make an application distributed with cygwin ? :-) Regards Ralf
RE: problem with make
-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 this ? I have no problem to fix this, if somebody could give me a direction where I have to look on. ... get the KDE team to fix their makefiles. They have done this. Rob
