• Kramer (30/30) Jan 27 2005 I've download MinTL and am having some difficulties getting it to work.....
• Ben Hinkle (20/61) Jan 28 2005 I wasn't able to reproduce the error - could you either post or email me...
• Kramer (23/88) Jan 28 2005 I changed my configuration file and this works like a champ if I /don't/...
• Ben Hinkle (15/41) Jan 28 2005 Adding the mintl directory to the library search path doesn't include th...
• Kramer (3/46) Jan 28 2005 Thanks for the help! :)
• Ben Hinkle (14/22) Jan 28 2005 ah - I think I see what happened. I bet you tried

Kramer <Kramer_member pathlink.com> writes:

I've download MinTL and am having some difficulties getting it to work...

I'm running WinXP, DMD 0.111, MinTL ver.? (whatever is currently on Ben's
website)

What works:
1) The make file does it's thing without a hitch...
2) I've taken the sample program in the MinTL documentation (as listed in the
"Build and Install" section) and have successfully compiled that when I compile
right above the mintl directory and use the compiler flag -release.

What doesn't work:
1) If I leave out the -release flag (but still right above the mintl directory)
I get the following errors (even though I have both the mintl.lib and
mintl_debug.lib in the library path):
testmintlapp.obj(testmintlapp)
Error 42: Symbol Undefined _assert_5mintl4list
testmintlapp.obj(testmintlapp)
Error 42: Symbol Undefined _array_5mintl4list
2) I don't think this is a MinTL issue, but I'll list it anyways since I'm
confused on how it works.  If I don't compile above the mintl directory but use
the compiler -I flag to point it to the directory with all the mintl source
files, the compiler says it can't read (for my example) "mintl\list.d".  Then if
I include list.d in the compile command line it bawks at the next file it says
it can't read.  I'm running on WinXP and use spaces in my paths (i.e. c:\my
documents\my code\d").  I'm not sure, but I don't think dmd likes the spaces in
paths.

Is there any solution for the import issue?

General library question: When I use phobos modules, why doesn't the compiler
complain it can't find the imports.  Is the compiler hard-coded with an import
path?  Is there a way to compile all the MinTL source files into one library
that I can just link to without having to specify an import path?

-Kramer

"Ben Hinkle" <ben.hinkle gmail.com> writes:

"Kramer" <Kramer_member pathlink.com> wrote in message 
news:ctcgm3$13q4$1 digitaldaemon.com...
 I've download MinTL and am having some difficulties getting it to work...

 I'm running WinXP, DMD 0.111, MinTL ver.? (whatever is currently on Ben's
 website)

 What works:
 1) The make file does it's thing without a hitch...
 2) I've taken the sample program in the MinTL documentation (as listed in 
 the
 "Build and Install" section) and have successfully compiled that when I 
 compile
 right above the mintl directory and use the compiler flag -release.

 What doesn't work:
 1) If I leave out the -release flag (but still right above the mintl 
 directory)
 I get the following errors (even though I have both the mintl.lib and
 mintl_debug.lib in the library path):
 testmintlapp.obj(testmintlapp)
 Error 42: Symbol Undefined _assert_5mintl4list
 testmintlapp.obj(testmintlapp)
 Error 42: Symbol Undefined _array_5mintl4list
 2) I don't think this is a MinTL issue, but I'll list it anyways since I'm
 confused on how it works.  If I don't compile above the mintl directory 
 but use
 the compiler -I flag to point it to the directory with all the mintl 
 source
 files, the compiler says it can't read (for my example) "mintl\list.d". 
 Then if
 I include list.d in the compile command line it bawks at the next file it 
 says
 it can't read.  I'm running on WinXP and use spaces in my paths (i.e. 
 c:\my
 documents\my code\d").  I'm not sure, but I don't think dmd likes the 
 spaces in
 paths.

 Is there any solution for the import issue?

I wasn't able to reproduce the error - could you either post or email me the 
exact steps you took from a fresh MinTL install? Try not rebuilding the 
library since maybe the rebuild overwrote something important. For example I 
can imagine it's pretty easy to run make and it builds mintl_debug.lib but 
with the -release option or something.

 General library question: When I use phobos modules, why doesn't the 
 compiler
 complain it can't find the imports.  Is the compiler hard-coded with an 
 import
 path?  Is there a way to compile all the MinTL source files into one 
 library
 that I can just link to without having to specify an import path?

The path to phobos is set in the file "dmd\bin\sc.ini" on Windows and in 
"dmd.conf" on Linux. So to add other packages to the list modify sc.ini to 
say something like
  LIB="% P%\..\lib";\dm\lib;"C:\d\mintl"
  DFLAGS="-I% P%\..\src\phobos";"C:\d"
(where MinTL was unpacked in C:\d) then building something like
  dmd test.d mintl_debug.lib
will look for the module mintl.list in C:\d\mintl\list.d and mintl_debug.lib 
in C:\d\mintl\mintl_debug.lib
I tried renaming my "d" directory to "d code" and I couldn't get anything to 
work. Maybe I'm not quoting the paths correctly but assuming I am I agree 
that it seems like dmd doesn't like directories with spaces in the names.

-Ben 

Kramer <Kramer_member pathlink.com> writes:

In article <ctde1h$2g36$1 digitaldaemon.com>, Ben Hinkle says...
"Kramer" <Kramer_member pathlink.com> wrote in message 
news:ctcgm3$13q4$1 digitaldaemon.com...
 I've download MinTL and am having some difficulties getting it to work...

 I'm running WinXP, DMD 0.111, MinTL ver.? (whatever is currently on Ben's
 website)

 What works:
 1) The make file does it's thing without a hitch...
 2) I've taken the sample program in the MinTL documentation (as listed in 
 the
 "Build and Install" section) and have successfully compiled that when I 
 compile
 right above the mintl directory and use the compiler flag -release.

 What doesn't work:
 1) If I leave out the -release flag (but still right above the mintl 
 directory)
 I get the following errors (even though I have both the mintl.lib and
 mintl_debug.lib in the library path):
 testmintlapp.obj(testmintlapp)
 Error 42: Symbol Undefined _assert_5mintl4list
 testmintlapp.obj(testmintlapp)
 Error 42: Symbol Undefined _array_5mintl4list
 2) I don't think this is a MinTL issue, but I'll list it anyways since I'm
 confused on how it works.  If I don't compile above the mintl directory 
 but use
 the compiler -I flag to point it to the directory with all the mintl 
 source
 files, the compiler says it can't read (for my example) "mintl\list.d". 
 Then if
 I include list.d in the compile command line it bawks at the next file it 
 says
 it can't read.  I'm running on WinXP and use spaces in my paths (i.e. 
 c:\my
 documents\my code\d").  I'm not sure, but I don't think dmd likes the 
 spaces in
 paths.

 Is there any solution for the import issue?

I wasn't able to reproduce the error - could you either post or email me the 
exact steps you took from a fresh MinTL install? Try not rebuilding the 
library since maybe the rebuild overwrote something important. For example I 
can imagine it's pretty easy to run make and it builds mintl_debug.lib but 
with the -release option or something.

 General library question: When I use phobos modules, why doesn't the 
 compiler
 complain it can't find the imports.  Is the compiler hard-coded with an 
 import
 path?  Is there a way to compile all the MinTL source files into one 
 library
 that I can just link to without having to specify an import path?

The path to phobos is set in the file "dmd\bin\sc.ini" on Windows and in 
"dmd.conf" on Linux. So to add other packages to the list modify sc.ini to 
say something like
  LIB="% P%\..\lib";\dm\lib;"C:\d\mintl"
  DFLAGS="-I% P%\..\src\phobos";"C:\d"
(where MinTL was unpacked in C:\d) then building something like
  dmd test.d mintl_debug.lib
will look for the module mintl.list in C:\d\mintl\list.d and mintl_debug.lib 
in C:\d\mintl\mintl_debug.lib
I tried renaming my "d" directory to "d code" and I couldn't get anything to 
work. Maybe I'm not quoting the paths correctly but assuming I am I agree 
that it seems like dmd doesn't like directories with spaces in the names.

-Ben 

I changed my configuration file and this works like a champ if I /don't/ specify
a library right after my source file /and/ specify the -release flag.  If I
leave out the relase flag, then it still complains about undefined symbols.

So:


dmd TestMinTLApp.d  -v


found
dmd TestMinTLApp.d mintl_debug.lib -v

If I add -release to either of the above command, it works, except when the
library is specified, then it still complains it can't find it.  Might that make
more sense in an if/else block? <g>

I'm sure most of this is just due to my not understanding of how libraries and
linking works and if you have LIB set in the dmd configuration file but also as
an environment variable on your OS, which one takes precedence.  Given all that,
I do like it when it does work and I want more of that. :)

I've checked the Wiki and there seems to be plenty of examples on how to code in
D, but not much (that I could find) on actually using and getting the most out
of dmd and the other tools.  Does anyone have anything like that?  Might that be
useful?  For myself I know I've spent more time in tool and environment
configuration than in D coding. :(

-Kramer

"Ben Hinkle" <bhinkle mathworks.com> writes:

 dmd TestMinTLApp.d  -v

Adding the mintl directory to the library search path doesn't include the 
library itself - it just says where to look for the library. So you still 
have to list either mintl.lib or mintl_debug.lib on the command line. There 
probably is a way to always include the mintl library without having to list 
it on the command line but I don't know how to do that.


 not
 found
 dmd TestMinTLApp.d mintl_debug.lib -v

The symbols it can't find should be in mintl_debug.lib so getting that 
library should solve your other problems. Check to see if the library exists 
in the mintl directory. If no then extract it from the zip file again 
because it got deleted at some proint (probably during a rebuild). If the 
library is there then the paths listed in the sc.ini are probably wrong.

 If I add -release to either of the above command, it works, except when 
 the
 library is specified, then it still complains it can't find it.  Might 
 that make
 more sense in an if/else block? <g>

The reason why -release simplifies life is that most of mintl is a bunch of 
templates so the mintl_debug.lib really just has a few Exception classes and 
lots of assert functions and little else.

 I'm sure most of this is just due to my not understanding of how libraries 
 and
 linking works and if you have LIB set in the dmd configuration file but 
 also as
 an environment variable on your OS, which one takes precedence.  Given all 
 that,
 I do like it when it does work and I want more of that. :)

 I've checked the Wiki and there seems to be plenty of examples on how to 
 code in
 D, but not much (that I could find) on actually using and getting the most 
 out
 of dmd and the other tools.  Does anyone have anything like that?  Might 
 that be
 useful?  For myself I know I've spent more time in tool and environment
 configuration than in D coding. :(

I don't know of any pages like that. It would be nice since these things can 
get frustrating. 

Kramer <Kramer_member pathlink.com> writes:

Thanks for the help! :)

-Kramer

In article <cte6cl$f96$1 digitaldaemon.com>, Ben Hinkle says...

 dmd TestMinTLApp.d  -v

Adding the mintl directory to the library search path doesn't include the 
library itself - it just says where to look for the library. So you still 
have to list either mintl.lib or mintl_debug.lib on the command line. There 
probably is a way to always include the mintl library without having to list 
it on the command line but I don't know how to do that.


 not
 found
 dmd TestMinTLApp.d mintl_debug.lib -v

The symbols it can't find should be in mintl_debug.lib so getting that 
library should solve your other problems. Check to see if the library exists 
in the mintl directory. If no then extract it from the zip file again 
because it got deleted at some proint (probably during a rebuild). If the 
library is there then the paths listed in the sc.ini are probably wrong.

 If I add -release to either of the above command, it works, except when 
 the
 library is specified, then it still complains it can't find it.  Might 
 that make
 more sense in an if/else block? <g>

The reason why -release simplifies life is that most of mintl is a bunch of 
templates so the mintl_debug.lib really just has a few Exception classes and 
lots of assert functions and little else.

 I'm sure most of this is just due to my not understanding of how libraries 
 and
 linking works and if you have LIB set in the dmd configuration file but 
 also as
 an environment variable on your OS, which one takes precedence.  Given all 
 that,
 I do like it when it does work and I want more of that. :)

 I've checked the Wiki and there seems to be plenty of examples on how to 
 code in
 D, but not much (that I could find) on actually using and getting the most 
 out
 of dmd and the other tools.  Does anyone have anything like that?  Might 
 that be
 useful?  For myself I know I've spent more time in tool and environment
 configuration than in D coding. :(

I don't know of any pages like that. It would be nice since these things can 
get frustrating. 

"Ben Hinkle" <ben.hinkle gmail.com> writes:

 1) If I leave out the -release flag (but still right above the mintl 
 directory)
 I get the following errors (even though I have both the mintl.lib and
 mintl_debug.lib in the library path):
 testmintlapp.obj(testmintlapp)
 Error 42: Symbol Undefined _assert_5mintl4list
 testmintlapp.obj(testmintlapp)
 Error 42: Symbol Undefined _array_5mintl4list

ah - I think I see what happened. I bet you tried
  dmd test.d mintl.lib
instead of
  dmd test.d mintl_debug.lib
The Build and Install instructions have the first line when it should have 
the second line. I'll update those instructions to be more explicit about 
when to type
  dmd test.d -release mintl.lib
vs
  dmd test.d mintl_debug.lib
And I'll take out the part that suggests you always rebuild the library. 
Instead I'll suggest people stick with the pre-built versions unless they 
want to change some compiler flags.

-Ben