I am trying to make the transition from C++ to D. I've hit a snag with the etc.c.zlib module where any attempt to use this module to open a file yields an error:
Error 42: Symbol Undefined __lseeki64.

Here is a simple example of code that gives the error upon compilation.

import std.stdio;
import etc.c.zlib;

void main(string[] args)
{
	char[] fName = "C:\\Users\\Matthew Gamble\\Documents\\sample.bam\0".dup;
	char[] mode ="r\0".dup;
	gzFile bamFile; //no error here
	bamFile = gzopen(&fName[0],&mode[0]); //this is where the error hits
}

I'm using DMD32 D Compiler v2.067.1 on a windows 8 64 bit machine. Working from either Visual D in Visual Studio 2013 Community and Coedit as IDEs gives the error. I'm probably doing something obviously wrong, so have mercy. If etc.c.zlib is not the preferred way to read from a binary gzipped file any advice would be appreciated. Thanks.

On Thursday, 2 July 2015 at 03:07:43 UTC, Matthew Gamble wrote:
> I am trying to make the transition from C++ to D. I've hit a snag with the etc.c.zlib module where any attempt to use this module to open a file yields an error:
> Error 42: Symbol Undefined __lseeki64.
>
> Here is a simple example of code that gives the error upon compilation.
>
> import std.stdio;
> import etc.c.zlib;
>
> void main(string[] args)
> {
> 	char[] fName = "C:\\Users\\Matthew Gamble\\Documents\\sample.bam\0".dup;
> 	char[] mode ="r\0".dup;
> 	gzFile bamFile; //no error here
> 	bamFile = gzopen(&fName[0],&mode[0]); //this is where the error hits
> }
>

Is that a compiler error or a linker error?

>I'm probably doing something obviously wrong, so have mercy. If etc.c.zlib
> is not the preferred way to read from a binary gzipped file any advice would be appreciated. Thanks.

>char[] fName = "C:\\Users\\Matthew Gamble\\Documents\\sample.bam\0".dup;
>bamFile = gzopen(&fName[0],&mode[0]);

would be probably be more easily understood if written as:
string fName  = "C:\\Users\\Matthew Gamble\\Documents\\sample.bam";
bamFile = gzopen(fName.ptr,mode.ptr);

as string _literals_ are nul terminated in D ( but not dynamically constructed ones: use .toStringz on them) assuming that gzopen doesn't manipulate it's arguments (I would very much doubt that).

Also if you're trying to do bam parsing/manipulating/whatever try to get a hold of Artem Tarasov who occasionally posts on these forums. He wrote the worlds fastest bam parser in D. He might be able to give you some hints on further questions.

On Thursday, 2 July 2015 at 12:36:35 UTC, Nicholas Wilson wrote:
> On Thursday, 2 July 2015 at 03:07:43 UTC, Matthew Gamble wrote:
>> I am trying to make the transition from C++ to D. I've hit a snag with the etc.c.zlib module where any attempt to use this module to open a file yields an error:
>> Error 42: Symbol Undefined __lseeki64.
>>
>> Here is a simple example of code that gives the error upon compilation.
>>
>> import std.stdio;
>> import etc.c.zlib;
>>
>> void main(string[] args)
>> {
>> 	char[] fName = "C:\\Users\\Matthew Gamble\\Documents\\sample.bam\0".dup;
>> 	char[] mode ="r\0".dup;
>> 	gzFile bamFile; //no error here
>> 	bamFile = gzopen(&fName[0],&mode[0]); //this is where the error hits
>> }
>>
>
> Is that a compiler error or a linker error?
>
>>I'm probably doing something obviously wrong, so have mercy. If etc.c.zlib
>> is not the preferred way to read from a binary gzipped file any advice would be appreciated. Thanks.
>
>>char[] fName = "C:\\Users\\Matthew Gamble\\Documents\\sample.bam\0".dup;
>>bamFile = gzopen(&fName[0],&mode[0]);
>
> would be probably be more easily understood if written as:
> string fName  = "C:\\Users\\Matthew Gamble\\Documents\\sample.bam";
> bamFile = gzopen(fName.ptr,mode.ptr);
>
> as string _literals_ are nul terminated in D ( but not dynamically constructed ones: use .toStringz on them) assuming that gzopen doesn't manipulate it's arguments (I would very much doubt that).
>
> Also if you're trying to do bam parsing/manipulating/whatever try to get a hold of Artem Tarasov who occasionally posts on these forums. He wrote the worlds fastest bam parser in D. He might be able to give you some hints on further questions.

Thanks for the style tips. I will incorporate them in the future.
I was digging through Artem's BAM parser code and it also makes use of a stripped down version of etc.c.zlib, so it seems like I would have the same problem if I was to compile his parser, but I can try that and perhaps alter my program to make use of pipes from Sambamba. That's not something I've considered before.

However, I only need the positional and flag information from the BAM files and I have previously written a parser in C++ using zlib that could do the job. I was just trying to move that parser over to D as a learning experience and so that I could easily incorporate it with the other programs I will write in D.

Here is the full output upon building the program in VS2013 with Visual D:

------ Build started: Project: zlibTest, Configuration: Release Win32 ------
Building Release\zlibTest.exe...
OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
C:\D\dmd2\windows\bin\..\lib\phobos.lib(gzlib)
 Error 42: Symbol Undefined __lseeki64
Building Release\zlibTest.exe failed!
Details saved as "file://C:\Users\Matthew Gamble\documents\visual studio 2013\Projects\file_readers\ConsoleApp1\Release\zlibTest.buildlog.html"
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========

Seems like a linking issue. I tried adding "C:\D\dmd2\windows\lib" to the lib search path in the linker properties in VS, But that did not help.

I would have thought that linking to a module in phobos would be automatic, like for std.stdio. Is that not the case?

Any advice or tips would be appreciated.

Thanks,

Matt

On Thursday, 2 July 2015 at 03:07:43 UTC, Matthew Gamble wrote:
> I am trying to make the transition from C++ to D. I've hit a snag with the etc.c.zlib module where any attempt to use this module to open a file yields an error:
> Error 42: Symbol Undefined __lseeki64.
>
> Here is a simple example of code that gives the error upon compilation.
>
> import std.stdio;
> import etc.c.zlib;
>
> void main(string[] args)
> {
> 	char[] fName = "C:\\Users\\Matthew Gamble\\Documents\\sample.bam\0".dup;
> 	char[] mode ="r\0".dup;
> 	gzFile bamFile; //no error here
> 	bamFile = gzopen(&fName[0],&mode[0]); //this is where the error hits
> }
>
> I'm using DMD32 D Compiler v2.067.1 on a windows 8 64 bit machine. Working from either Visual D in Visual Studio 2013 Community and Coedit as IDEs gives the error. I'm probably doing something obviously wrong, so have mercy. If etc.c.zlib is not the preferred way to read from a binary gzipped file any advice would be appreciated. Thanks.

Hi.

The etc.c.zlib headers are, I think, just translations of the C headers and allow you to link with an external library.  If the library is not installed, or the compiler/linker cannot find them then you may have a link error.  Are you sure that Visual Studio knows where to find the zlib library binary ?  Can you try compiling your project with DMD from the command line appending -L-lz (that might work on linux, but I don't know on windows)?  There is a program called everything from void tools that may be helpful in finding the library file if its location is not obvious.

Laeeth

On Thursday, 2 July 2015 at 20:19:49 UTC, Laeeth Isharc wrote:
> On Thursday, 2 July 2015 at 03:07:43 UTC, Matthew Gamble wrote:
>> I am trying to make the transition from C++ to D. I've hit a snag with the etc.c.zlib module where any attempt to use this module to open a file yields an error:
>> Error 42: Symbol Undefined __lseeki64.
>>
>> Here is a simple example of code that gives the error upon compilation.
>>
>> import std.stdio;
>> import etc.c.zlib;
>>
>> void main(string[] args)
>> {
>> 	char[] fName = "C:\\Users\\Matthew Gamble\\Documents\\sample.bam\0".dup;
>> 	char[] mode ="r\0".dup;
>> 	gzFile bamFile; //no error here
>> 	bamFile = gzopen(&fName[0],&mode[0]); //this is where the error hits
>> }
>>
>> I'm using DMD32 D Compiler v2.067.1 on a windows 8 64 bit machine. Working from either Visual D in Visual Studio 2013 Community and Coedit as IDEs gives the error. I'm probably doing something obviously wrong, so have mercy. If etc.c.zlib is not the preferred way to read from a binary gzipped file any advice would be appreciated. Thanks.
>
> Hi.
>
> The etc.c.zlib headers are, I think, just translations of the C headers and allow you to link with an external library.  If the library is not installed, or the compiler/linker cannot find them then you may have a link error.  Are you sure that Visual Studio knows where to find the zlib library binary ?  Can you try compiling your project with DMD from the command line appending -L-lz (that might work on linux, but I don't know on windows)?  There is a program called everything from void tools that may be helpful in finding the library file if its location is not obvious.
>
> Laeeth

Thanks to Nicholas and Laeeth for all the suggestions. In the process of trying to explicitly link to zlib.dll like a do for C++, I came across a strange development. I changed the platform to x64 (Visual D) and now the program compiles and runs fine without errors. This is without pointing the linker to zlib.dll. While this allows me to continue developing my program, I'm a bit concerned about why this would fix the error and why etc.c.zlib cannot be compiled for 32bit on a 64bit machine(Windows). Does this give anyone any insights into this problem?

Best,
Matt

On 7/3/2015 8:44 AM, Matthew Gamble wrote:
> Thanks to Nicholas and Laeeth for all the suggestions. In the process of
> trying to explicitly link to zlib.dll like a do for C++, I came across a
> strange development. I changed the platform to x64 (Visual D) and now
> the program compiles and runs fine without errors. This is without
> pointing the linker to zlib.dll. While this allows me to continue
> developing my program, I'm a bit concerned about why this would fix the
> error and why etc.c.zlib cannot be compiled for 32bit on a 64bit
> machine(Windows). Does this give anyone any insights into this problem?
>
The Phobos source actually includes the C source for zlib. You can find it in the DMD distribution in src/phobos/etc/c/zlib/. When Phobos is compiled, it also compiles zlib and pulls the library into the final Phobos lib. You don't need the zlib DLL.

You have no error in 64-bit because it's working as expected. The trick now is to determine what's screwing things up in 32-bit. The starting point is at [1]. A quick bit of googling appears to suggest that _lseeki64 is a function specific to the Microsoft C runtime. I assume you're seeing the linker error because the DMC C runtime, which is the default used by DMD on Windows, does not include this function. If you compile using -m32mscoff (which also requires compiling a compatible version of Phobos), you'll be using the MS toolchain for 32-bit and the error should go away.

This is all assumption, but it's where I would start. And if this actually is the issue ([2] suggests it is), I'm surprised it hasn't turned up before now.

[1] https://github.com/D-Programming-Language/phobos/blob/master/etc/c/zlib/gzlib.c#L8
[2] http://www.digitalmars.com/d/archives/c++/windows/32-bits/440.html

On Friday, 3 July 2015 at 02:16:45 UTC, Mike Parker wrote:
> On 7/3/2015 8:44 AM, Matthew Gamble wrote:
>>[...]
> The Phobos source actually includes the C source for zlib. You can find it in the DMD distribution in src/phobos/etc/c/zlib/. When Phobos is compiled, it also compiles zlib and pulls the library into the final Phobos lib. You don't need the zlib DLL.
>
> You have no error in 64-bit because it's working as expected. The trick now is to determine what's screwing things up in 32-bit. The starting point is at [1]. A quick bit of googling appears to suggest that _lseeki64 is a function specific to the Microsoft C runtime. I assume you're seeing the linker error because the DMC C runtime, which is the default used by DMD on Windows, does not include this function. If you compile using -m32mscoff (which also requires compiling a compatible version of Phobos), you'll be using the MS toolchain for 32-bit and the error should go away.
>
> This is all assumption, but it's where I would start. And if this actually is the issue ([2] suggests it is), I'm surprised it hasn't turned up before now.
>
> [1] https://github.com/D-Programming-Language/phobos/blob/master/etc/c/zlib/gzlib.c#L8
> [2] http://www.digitalmars.com/d/archives/c++/windows/32-bits/440.html

Wow Mike. This seems like the most likely explanation to me. I'm a bit hesitant to compile phobos from source on this machine with -m32mscoff. Perhaps a similar test would be to compile my program on a 32-bit windows machine? I can do this at work on Monday. If you are correct is this something that should be reported and where would I do that?

Best,

Matt

On Friday, 3 July 2015 at 16:28:29 UTC, Matthew Gamble wrote:
> On Friday, 3 July 2015 at 02:16:45 UTC, Mike Parker wrote:
>> On 7/3/2015 8:44 AM, Matthew Gamble wrote:
>>>[...]
>> The Phobos source actually includes the C source for zlib. You can find it in the DMD distribution in src/phobos/etc/c/zlib/. When Phobos is compiled, it also compiles zlib and pulls the library into the final Phobos lib. You don't need the zlib DLL.
>>
>> You have no error in 64-bit because it's working as expected. The trick now is to determine what's screwing things up in 32-bit. The starting point is at [1]. A quick bit of googling appears to suggest that _lseeki64 is a function specific to the Microsoft C runtime. I assume you're seeing the linker error because the DMC C runtime, which is the default used by DMD on Windows, does not include this function. If you compile using -m32mscoff (which also requires compiling a compatible version of Phobos), you'll be using the MS toolchain for 32-bit and the error should go away.
>>
>> This is all assumption, but it's where I would start. And if this actually is the issue ([2] suggests it is), I'm surprised it hasn't turned up before now.
>>
>> [1] https://github.com/D-Programming-Language/phobos/blob/master/etc/c/zlib/gzlib.c#L8
>> [2] http://www.digitalmars.com/d/archives/c++/windows/32-bits/440.html
>
> Wow Mike. This seems like the most likely explanation to me. I'm a bit hesitant to compile phobos from source on this machine with -m32mscoff. Perhaps a similar test would be to compile my program on a 32-bit windows machine? I can do this at work on Monday. If you are correct is this something that should be reported and where would I do that?
>
> Best,
>
> Matt

BTW just so you know, having had a few horrendous experiences of installing other programs from scratch under linux with recursive pain when other programs they pull in also had problems: dmd + phobos are extremely easy and quick to compile (based on my own experience, which is all I can speak of).

There are personal psychological benefits to going through the experience once because one no longer thinks of things as a closed box one dare not touch, and acquires a deeper knowledge of the language and library.  And it won't mess up your main install of dmd because make install puts the files in a subdirectory (at least on linux - you should check if true of windows,but I should think so) rather than touching the base install.

On 7/4/2015 1:28 AM, Matthew Gamble wrote:

>
> Wow Mike. This seems like the most likely explanation to me. I'm a bit
> hesitant to compile phobos from source on this machine with -m32mscoff.
> Perhaps a similar test would be to compile my program on a 32-bit
> windows machine? I can do this at work on Monday. If you are correct is
> this something that should be reported and where would I do that?

You shouldn't have no problems compiling it on any Windows box. It isn't going to mess anything up. I'm running Windows 7 64-bit and I can use the default 32-bit toolchain, the m32mscoff toolchain and the m64 toolchain without issue.

It's probably easiest to do if you have a version of Visual Studio installed (I use 2013 community). To compile the m32mscoff version, I did the following:

1. Open the VS2013 x86 Native Tools Command Prompt
2. set cl32=%VCINSTALLDIR%/bin/cl.exe
3. set ar32=%VCINSTALLDIR%/bin/lib.exe
4. cd druntime
5. %dm_make% -f win64.mak DMD=%DMD% MODEL=32mscoff "CC=\"%cl32%\""
6. cd ../phobos
7. %dm_make% -f win64.mak DMD=%DMD% MODEL=32mscoff "CC=\"%cl32%\"" MAKE=%dm_make% "AR=\"%ar32%\""

This creates a phobos32mscoff.lib, which you can then put anywhere on your lib path. I took the steps to compile from Rainer Schuetze's post at [1]. You may need to take additional steps, depending on whether the DMD and DM make are on your path, or if you've already compiled the source for another configuration. It's all there in his post.

[1] http://forum.dlang.org/post/m456t5$2jc4$1@digitalmars.com

Oh, and issues should be reported at https://issues.dlang.org/.