RE: [Boost-Users] [date_time] library binaries for VC7.1? && Comm on lib placement
Dan,
The date_time.lib library is a static lib. The built date_time.dll actually
has no exports in it, so for VC purposes is useless. I would say don't
worry about it, and just use the static lib.
On a side note, has anyone been working on placing built items into a common
directory, say
-----Original Message----- From: Dan Muller [mailto:yg-boost-users@m.gmane.org] Sent: Thursday, August 14, 2003 11:38 AM To: boost-users@yahoogroups.com Subject: [Boost-Users] [date_time] library binaries for VC7.1?
I've been using boost for a while, but now for the first time I'm using a component that isn't entirely header-based, namely date_time in boost 1.30.0.
After building boost for VC7.1, I find a .lib file in boost_1_30_0\libs\date_time\build\bin\libboost_date_time.lib\m svc\debug \runtime-link-dynamic and a .dll in boost_1_30_0\libs\date_time\build \bin\boost_date_time.dll\msvc\debug\runtime-link-dynamic.
There are a couple of things that I don't understand about these files.
Is the .lib file supposed to be the import library for the .dll? Linking against the .lib file hasn't produced any import references in my applications. Perhaps I'm just not hitting any out-of-line functionality, but it sure seems like the .lib file is a static library rather than an import library.
Also, running DUMPBIN /EXPORTS on the .dll file shows no exported symbols related to date_time classes, as far as I can see. It really looks like it's exporting a bunch of stuff related to the standard C++ library, which makes no sense to me.
Can anyone clear up my confusion?
-- Dan Muller "So that's what an invisible barrier looks like!" (Time Bandits)
------------------------ Yahoo! Groups Sponsor ---------------------~--> Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511 http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/EbFolB/TM -------------------------------------------------------------- -------~->
Info: http://www.boost.org Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl Unsubscribe: mailto:boost-users-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
On Thu, 14 Aug 2003 13:47:10 -0700, Administrator wrote
Dan,
The date_time.lib library is a static lib. The built date_time.dll actually has no exports in it, so for VC purposes is useless. I would say don't worry about it, and just use the static lib.
Exactly. I think the problem is that the build appears to be building a valid .dll. I've wanted to turn this off, but I couldn't figure out the jamfile magic to make this happen and ran out of time to pursue it. It's on my todo list to fix this, but for now just use the static lib. Jeff
Jeff Garland wrote:
On Thu, 14 Aug 2003 13:47:10 -0700, Administrator wrote
Dan,
The date_time.lib library is a static lib. The built date_time.dll actually has no exports in it, so for VC purposes is useless. I would say don't worry about it, and just use the static lib.
Exactly. I think the problem is that the build appears to be building a valid .dll. I've wanted to turn this off, but I couldn't figure out the jamfile magic to make this happen and ran out of time to pursue it. It's on my todo list to fix this, but for now just use the static lib.
Is there a reason why the date/time library can not also be built as a DLL for Windows ?
On Thu, 14 Aug 2003 20:29:31 -0400, Edward Diener wrote
Is there a reason why the date/time library can not also be built as a DLL for Windows ?
No, don't think so. The entry points and symbol entries just need to be defined. It's probably 30 minutes of work for someone with the MS compiler handy (I don't have MSVC installed unless I'm being paid to use it :-). So maybe someone wants to volunteer and send me some patches to apply? I'll be happy to answer detailed questions off-list... Jeff
In article <41B553DE6D81D5119AD90050DA7ACF702E62E6@PDCSERVER>, administrator@sbcltd.com says...
Dan,
The date_time.lib library is a static lib. The built date_time.dll actually has no exports in it, so for VC purposes is useless. I would say don't worry about it, and just use the static lib.
Thanks, Dale, this is exactly what I needed to know. I was starting to worry that I didn't understand DUMPBIN's output, which would be worrisome since I've been using it for years. :-)
On a side note, has anyone been working on placing built items into a common directory, say
/lib? If not, I have a patch that should help alot.
Sounds like an excellent idea. I'm assuming that on Windows, the boost build would then follow common conventions so that libraries built with different characteristics (debug vs. non-debug, multi- vs. single- threaded, etc) had different names. (I haven't been following boost build developments lately -- is this a topic of ongoing changes?)
-----Original Message----- From: Dan Muller [mailto:yg-boost-users@m.gmane.org]
[text elided]
After building boost for VC7.1, I find a .lib file in boost_1_30_0\libs\date_time\build\bin\libboost_date_time.lib\m svc\debug \runtime-link-dynamic and a .dll in boost_1_30_0\libs\date_time\build \bin\boost_date_time.dll\msvc\debug\runtime-link-dynamic.
There are a couple of things that I don't understand about these files.
Is the .lib file supposed to be the import library for the .dll? Linking against the .lib file hasn't produced any import references in my applications. Perhaps I'm just not hitting any out-of-line functionality, but it sure seems like the .lib file is a static library rather than an import library.
Also, running DUMPBIN /EXPORTS on the .dll file shows no exported symbols related to date_time classes, as far as I can see. It really looks like it's exporting a bunch of stuff related to the standard C++ library, which makes no sense to me.
-- Dan Muller "So that's what an invisible barrier looks like!" (Time Bandits)
At 09:00 AM 8/18/2003, Dan Muller wrote:
In article <41B553DE6D81D5119AD90050DA7ACF702E62E6@PDCSERVER>, administrator@sbcltd.com says...
Dan,
On a side note, has anyone been working on placing built items into a common directory, say
/lib? If not, I have a patch that should help alot.
Sounds like an excellent idea. I'm assuming that on Windows, the boost build would then follow common conventions so that libraries built with different characteristics (debug vs. non-debug, multi- vs. single- threaded, etc) had different names. (I haven't been following boost build developments lately -- is this a topic of ongoing changes?)
A solution is currently checked in on a branch. But it is languishing for lack of testing. See the jamboost@yahoogroups.com thread "Standardization of build". I'm sure it would be appreciated if someone could give it a try and report problems to Rene. --Beman
participants (5)
-
Administrator -
Beman Dawes -
Dan Muller -
Edward Diener -
Jeff Garland