(Sometimes) Our application receives the following error at launch time,
before reaching main():
The procedure entry point _imp__ELUserHasLoggedIntoDatabase could not be
located in the dynamic link library ELLogin.dll
Q) How to determine the cause for this error?
Eg. is the symbol ill-defined? or is it ill-referenced by the caller?
dumpbin? or something? (what to look for, etc.)
It seems the error is dependent upon the build order of our frameworks, and
there are many frameworks. Any hints greatly appreciated.
I believe we are following the same _WINDOWS_DLL_GOOP as suggested (see
bbum's post below). Again, how to verify that we are, or are not?
Thanks!
- mk
WebObjects 3.5.1 / NT 4.0
---
NT import/export/extern Was: "Re: gdb techniques?"
Bill Bumgarner ([EMAIL PROTECTED])
Fri, 5 Feb 1999 12:53:36 -0500 (EST)
All of the "gdb techniques" stuff was very interesting-- but I don't think
it'll actually help solve this problem.
This problem stinks of the NT ANSI extern's aren't good enough problem.
In particular, looking at self via the stack shows a viable object whereas
examining self directly shows "<not an object>". I'd wager that if you
did p *self, you would see a structure full of 0/nil?
Unfortunately, the NT linker doesn't like the standard "extern" style
variable declarations typically used to export symbols from a DLL that may
be used by other compiled code (i.e. extern NSString
*MyFrameworkException;).
Instead, "externs" must be declared differently depending on whether you
are compiling the framework itself or using the framework (and its
headers) from somewhere else.
To do this-- switching the declaration depending on whether you are
building or not-- requires a #define that changes depending on whether you
are building the framework project or simply using the header from
somewhere else.
We use a mod to Maekfile.postamble, a FrameworkDefines.template file and
add the derived header to three different variables in Makefile.preamble.
Details follow.
Makefile.preamble:
OTHER_PUBLIC_HEADERS = $(DERIVED_SRC_DIR)/FrameworkDefines.h
OTHER_PRODUCT_DEPENDS = $(DERIVED_SRC_DIR)/FrameworkDefines.h
OTHER_SOURCEFILES = $(DERIVED_SRC_DIR)/FrameworkDefines.h
Makefile.postamble additions:
$(DERIVED_SRC_DIR)/FrameworkDefines.h: $(DERIVED_SRC_DIR) PB.project
Makefile
$(SILENT) $(ECHO) Creating FrameworkDefines.h from template.
$(SILENT) sed 's/<FRAMEWORK_NAME>/$(NAME)/g' < FrameworkDefines.template >
$(DERIVED_SRC_DIR)/FrameworkDefines.h
FrameworkDefines.template:
/*
* DO NOT MODIFY THIS FILE -- IT IS AUTOGENERATED!
*
* Platform specific defs for externs. This was pretty much
* copied from AppKitDefines.h
*/
//
// OpenStep/Mach
//
#if defined(__MACH__)
#ifdef __cplusplus
/*
* This isnt extern "C" because the compiler will not allow this if it has
* seen an extern "Objective-C"
*/
#define <FRAMEWORK_NAME>_EXTERN extern
#define PRIVATE_EXTERN __private_extern__
#else
#define <FRAMEWORK_NAME>_EXTERN extern
#define PRIVATE_EXTERN __private_extern__
#endif
#define <FRAMEWORK_NAME>_EXTERN_IMP PUBLIC_EXTERN
#define PRIVATE_EXTERN_IMP PRIVATE_EXTERN
//
// OpenStep/NT
//
#elif defined(WIN32)
#ifndef BUILDING_<FRAMEWORK_NAME>_DLL
#define <FRAMEWORK_NAME>_WINDOWS_DLL_GOOP __declspec(dllimport)
#else
#define <FRAMEWORK_NAME>_WINDOWS_DLL_GOOP __declspec(dllexport)
#endif
#ifdef __cplusplus
#define <FRAMEWORK_NAME>_EXTERN <FRAMEWORK_NAME>_WINDOWS_DLL_GOOP extern "C"
#define PRIVATE_EXTERN extern "C"
#else
#define <FRAMEWORK_NAME>_EXTERN <FRAMEWORK_NAME>_WINDOWS_DLL_GOOP extern
#define PRIVATE_EXTERN extern
#endif
#define <FRAMEWORK_NAME>_EXTERN_IMP PUBLIC_EXTERN
#define PRIVATE_EXTERN_IMP PRIVATE_EXTERN
//
// OpenStep/Solaris and/or Solaris/PDO
//
#elif defined(sun)
#ifdef __cplusplus
# define <FRAMEWORK_NAME>_EXTERN extern "C"
# define <FRAMEWORK_NAME>_PRIVATE_EXTERN extern "C"
#else
# define <FRAMEWORK_NAME>_EXTERN extern
# define <FRAMEWORK_NAME>_PRIVATE_EXTERN extern
#endif
#define <FRAMEWORK_NAME>_EXTERN_IMP <FRAMEWORK_NAME>_EXTERN
#define <FRAMEWORK_NAME>_PRIVATE_EXTERN_IMP PRIVATE_EXTERN
//
// PDO HP-UX
//
#elif defined(hpux)
#ifdef __cplusplus
# define <FRAMEWORK_NAME>_EXTERN extern "C"
# define <FRAMEWORK_NAME>_PRIVATE_EXTERN extern "C"
#else
# define <FRAMEWORK_NAME>_EXTERN extern
# define <FRAMEWORK_NAME>_PRIVATE_EXTERN extern
#endif
#define <FRAMEWORK_NAME>_EXTERN_IMP <FRAMEWORK_NAME>_EXTERN
#define <FRAMEWORK_NAME>_PRIVATE_EXTERN_IMP PRIVATE_EXTERN
#else
#error Do not know how to define extern on this platform
#endif
---
Once that is donw, declare all of your externs as <FRAMEWORK_NAME>_EXTERN,
where <FRAMEWORK_NAME> is the name of your framework project. It should
all just work.
Of course, this could be a completely different problem....
b.bum
On Thu, 4 Feb
1999, Christopher Nagel wrote:
> PLATFORM: NT 4.0 / WO 3.5.1
>
> Hello,
>
> I have an elusive memory/stack-corruption bug that I should very much
> like to see exterminated, but I'm afraid my skills with gdb are
> insufficient to the task. Does anyone know of resources (or might
> teach me) how to really swing in gdb?
>
> For example, from NeXTanswers, the way cool statement,
>
> (gdb) po *((id *)($fp +8))
>
> does what I thought "po self" should do (but "po self" says "<not an
> object>").
>
> Where can I go to learn what I need to understand in order to know
how
> to create a command like that? What is $fp, why +8, etc? Anyone
know
> what information in a DrWatson file would be useful?
>
> Does anyone have any tried-and-true techniques to share? I remember
> Julie Zelinsky (forgive the spelling if it's wrong) gave a very
> popular debugging seminar at a NeXTworld a million years ago, but I
> never saw any notes from it...
>
> Thanks very much for any hints/tips/urls you can provide!
>
> Chris
>
>
>
