471,582 Members | 1,434 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,582 software developers and data experts.

ordinal nnnn could not be located in the dynamic link library (my dll)

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
yh****@gmail.com

Jun 7 '06 #1
4 4273
Yahia,
Do you by chance regenerate the .def files when changing a library? If
so, you almost certainly have to rebuild every user of that library (since
the ordinal numbers tend to change with automated .def file generation).
Bob

<yh****@gmail.com> wrote in message
news:11**********************@j55g2000cwa.googlegr oups.com...
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
yh****@gmail.com

Jun 8 '06 #2
Bob,
Yes the .def files get regenerated.
However, they are exactly the same, confirmed with diff.
Therefore, I expect the libraries we generate with "lib -nologo
-out:JB.lib -def:JB.def" to be exactly the same as well.
YH

Jun 8 '06 #3
Bob,
Yes the .def files get regenerated.
However, they are exactly the same, confirmed with diff.
Therefore, I expect the libraries we generate with "lib -nologo
-out:JB.lib -def:JB.def" to be exactly the same as well.
YH

Jun 8 '06 #4
I figured out the .def files were the same BUT, the symbols files
generated with "dumpbin" utility : dumpbin -symbols -out:... Xobjects
.... were not the same.
The section corresponding to the Dump of the file I have modifed, and
this section only, was quite different, in particular the header
locations were not the same.

I have relinked all the dlls and the binary to make sure they all refer
to the same up to date .lib and now everything goes smoothly. Changes
in a source of one of the dlls does not produce strange "ordinal could
not be located" messages at runtime.

Watch out your development environment !

Thanx,

YH

Jun 8 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Ervin J. Obando | last post: by
reply views Thread by XIAOLAOHU | last post: by
reply views Thread by leo001 | last post: by
reply views Thread by lumer26 | last post: by
reply views Thread by Vinnie | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.