Y
yhebib
Hello All,
I've been browsing and reading all articles I could find on technet
,msdn and other knowledgeable sources to understand the issue I'm
dealing with.
However, I did not find so far how to fix that.
Investigations are still under progress and I hope you'll be able to
give hints or feedback that will drive me to the solution.
The applications I'm working on until the next release that will soon
go GA did not include any Windows platforms; just AIX and Solaris. For
this new release we've added XP and RedHat Linux.
All the GUI front-ends originally based on native Xview were ported to
Qt. That helped a lot in supporting Windows platforms.
These new applications version do not use any shared libraries, just
static libraries. That works fine for all platforms including Windows.
But now, we're in the process of changing that and migrating all our
static libraries to shared libraries for Unix and Windows platforms.
I have to confess that under Unix platforms it's just the matter of
recompiling the libraries to shared libs and recompiling the binaries
to use these shared libs.
Under windows XP with Visual Studio .Net 2003 I have the following
issue :
All the dlls use implicit export (about 200 dlls for 20 binaries).
For each library, we generate a .def file through "dumpbin" utility on
the .o files which is then parsed to obtain a well-formatted .def file
with ordinal numbers and function names.
Then we build the export libraries through "lib" utility using the .def
file we've generated above.
Then the dlls are built and the binaries linked.
So far, so good, the application starts normally. (we then have static
initialization order fiasco for our TLS variables but this is a
different story)
Then, I change one of the libs, the JB.lib library, I put a trace in
one of the functions - no new interfaces or change in any interfaces -
and the JB.dll gets built again.
Now if I start the same application I have a "ordinal nnnn could not be
located in the dynamic link library JB.dll"
This ordinal nnnn is in a range that has nothing to do with exports in
JB.dll (exports for JB.dll go from, ordinal 1 to 1520)
Dependency walker show me indeed a lot of unresolved symbols for the
application and all the dlls that depend on JB.dll.
All these unresolved symbols have ordinals far behind exports in
JB.dll.
I have tried to rebase all the dlls without any success.
Now, If I relink all JB.dll dependent dlls and the application, then
the application starts normally again.
As you can imagine, that's not acceptable since very heavy for our
development environment to relink all dependent dlls and applications
even when no interface has evolved.
We will, in a second phase, implement explicit export in all our shared
libraries. This implies a lot of changes in our 200 libraries. We will
code a batch that will do all these changes.
But for now we have strict deadlines and need to get the implicit
export version running.
Anyway, we may face the same issue even with the the explicit version.
Any hint or advice that you may have will be more than welcomed.
Cheers,
Yahia Hebib
(e-mail address removed)
I've been browsing and reading all articles I could find on technet
,msdn and other knowledgeable sources to understand the issue I'm
dealing with.
However, I did not find so far how to fix that.
Investigations are still under progress and I hope you'll be able to
give hints or feedback that will drive me to the solution.
The applications I'm working on until the next release that will soon
go GA did not include any Windows platforms; just AIX and Solaris. For
this new release we've added XP and RedHat Linux.
All the GUI front-ends originally based on native Xview were ported to
Qt. That helped a lot in supporting Windows platforms.
These new applications version do not use any shared libraries, just
static libraries. That works fine for all platforms including Windows.
But now, we're in the process of changing that and migrating all our
static libraries to shared libraries for Unix and Windows platforms.
I have to confess that under Unix platforms it's just the matter of
recompiling the libraries to shared libs and recompiling the binaries
to use these shared libs.
Under windows XP with Visual Studio .Net 2003 I have the following
issue :
All the dlls use implicit export (about 200 dlls for 20 binaries).
For each library, we generate a .def file through "dumpbin" utility on
the .o files which is then parsed to obtain a well-formatted .def file
with ordinal numbers and function names.
Then we build the export libraries through "lib" utility using the .def
file we've generated above.
Then the dlls are built and the binaries linked.
So far, so good, the application starts normally. (we then have static
initialization order fiasco for our TLS variables but this is a
different story)
Then, I change one of the libs, the JB.lib library, I put a trace in
one of the functions - no new interfaces or change in any interfaces -
and the JB.dll gets built again.
Now if I start the same application I have a "ordinal nnnn could not be
located in the dynamic link library JB.dll"
This ordinal nnnn is in a range that has nothing to do with exports in
JB.dll (exports for JB.dll go from, ordinal 1 to 1520)
Dependency walker show me indeed a lot of unresolved symbols for the
application and all the dlls that depend on JB.dll.
All these unresolved symbols have ordinals far behind exports in
JB.dll.
I have tried to rebase all the dlls without any success.
Now, If I relink all JB.dll dependent dlls and the application, then
the application starts normally again.
As you can imagine, that's not acceptable since very heavy for our
development environment to relink all dependent dlls and applications
even when no interface has evolved.
We will, in a second phase, implement explicit export in all our shared
libraries. This implies a lot of changes in our 200 libraries. We will
code a batch that will do all these changes.
But for now we have strict deadlines and need to get the implicit
export version running.
Anyway, we may face the same issue even with the the explicit version.
Any hint or advice that you may have will be more than welcomed.
Cheers,
Yahia Hebib
(e-mail address removed)