Issue Building dcload-ip

[Senk]

So, here comes the next issue I've got. I wanted to build dcload-ip because I own a broadband adapter that I wanted to use for developmental purposes with my Dreamcast. Unfortunately, when I attempt a make, I get the following error:

Code: Select all

make -C tool
make[2]: Entering directory `/home/rcsvt/cadcdev/dcload/dcload-ip/host-src/tool'
gcc -o dc-tool dc-tool.o syscalls.o unlink.o -L/opt/toolchains/dc/sh-elf/lib -lbfd -liberty -lintl 
/usr/bin/ld: cannot find -lintl
collect2: error: ld returned 1 exit status

I've checked my libraries and I do not have a libintl.a in either my standard /usr/lib/ directory or the additional library directory specified at /opt/toolchains/dc/sh-elf/lib/. I looked up the library and apparently something like it was included with the GNU gettext package; however, I get the feeling that I am supposed to be finding that library in /opt/toolchains/dc/sh-elf/lib/, which only contains libiberty.a. Is this a problem with me not having the library? Or was it supposed to have been built with the toolchain earlier? I've attempted to rename the libgnuintl.a to libintl.a from a build of gettext and pass that off as the library, but none of the needed functions are "found" in it even though a run of 'nm' indicates that they are in that library as well.

[BlueCrab]

Its not looking for a sh-elf libintl, as that's in building dc-tool, which is the program that runs on the PC-side. So, that's definitely an issue with your local Linux installation, for some reason.

[Senk]

So, removing the reference to the sh-elf lib directory and adding a reference to libdl.a let me build everything (I haven't tested it yet). I'm not sure why the reference to the sh-elf library is there if we aren't supposed to link to anything in that library for dc-tool, which is one of the programs built using the makefile and makefile.cfg.

Anyway, this is what I ended up using in Makefile.cfg:

Code: Select all

# Replaced the following
#BFDLIB         = -L/opt/toolchains/dc/sh-elf/lib -lbfd -liberty -lintl

# With this instead
BFDLIB          = -ldl -lbfd -liberty -lintl

From what I've read, libintl.a is being removed from a lot of programs? I'm not quite sure, but I had to grab libintl.a from the most recent gettext build that I can do... and it was in a hidden directory. Also, it looks like including that reference to the sh-elf directory caused an issue as it was checking libierty.a in that directory first... or something. I'm not really sure if I fixed anything at all at this point as I haven't tested anything that I've built yet. I don't own a crossover cable; so, I'm going to have to buy one along with a few blank CD-R's so I can set up the Dreamcast to communicate with my computer and then get dc-tool to work.

[BlueCrab]

The real reason it looks in that directory is because that's where the HOST libbfd gets installed by building the sh-elf targetted binutils. Most people on non-Linux systems don't have libbfd installed prior to building the toolchain, so we always just picked up the one that should get built with the toolchain (which no longer gets installed without a bit of extra work, which the dc-chain Makefile should take care of).

[Senk]

Wait, does that mean that I should have a libbfd in my /opt/toolchains/dc/sh-elf/lib/ directory? The only library I have is libiberty.a. Well, I'll know if dc-tool works as soon as I get a crossover cable tomorrow. I'm getting confused between what libraries were expected for me to have on my Linux machine and what libraries were supposed to be generated by the toolchain.

[BlueCrab]

Its possible that they changed the way to get libbfd to come out of the build again...

Either way, it shouldn't matter, as long as your libbfd supports ELF files, which it would on a Linux machine.