Compiling problem when linking to external libraries. - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: [1] 2   Go Down

Compiling problem when linking to external libraries.

  • 10 Replies
  • 6635 Views
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Compiling problem when linking to external libraries.
« on: 10 / May / 2012, 19:25:57 »
Advertisements
Take my word that this is related to CHDK.

I have a compiling problem that I require some expert advice on.
Internet browsing for solutions simply adds to the confusion.
To start at the end, I want to link a number of external libraries to a simple 'C' programme.

I use GrAnd's pre-built Windows environment.
The installation filepaths are :-

H:\CHDK\gcc\arm-elf
                    \etc
                    \bin\gmake.exe
                    \include
                    \share
                    \lib\gcc\arm-elf\3.4.6

In my PATH environment variable I just have the path to gmake.exe.
In bin,sh.exe is actually zsh.exe as renamed by GrAnd for some reason.
When I type gmake, Windows can find it and execute it.

How does gmake know the absolute or relative  location of the include and lib directories ?

Do I have a 'MINGW  installation' ?
In effect, am I in a Unix environment?

When studying gcc compiling, it states the default locations for headers amd libraries is usr\local\include, usr\local\lib,usr\include and usr\lib.

How does that relate to my file structure on Windows ?

It makes the gcc discussions of relative paths difficult to understand.

I have also found that gcc examples that place -I and -L folders before the .C files do not work, the compiler complains there are no 'c files.

I am trying to use the ffmpeg libraries.

I have put avcodec.h,avformat.h and avio.h in \include.

Because those headers have references to #include "libavutil/.." and #include "libavcodec/.." I have created folders '\include\libavcodec','\include\libavutil' and others.

I have also created \lib\libavc for the ten .dll.a library files.
Despite their extension, I assume they are the static libraries.
There are also nine similar files but with name ending .lib.
They all start with '!<arch>'.

Finally to the question .. how do I reference the include and library files using relative paths, I assume that I do not have to give the absolute path to every library file ?

Needless to say, the library functions always fail to be found with every option that I have tried.


David
Logged
*

Offline reyalp

  • ******
  • 14128
Re: Compiling problem when linking to external libraries.
« Reply #1 on: 11 / May / 2012, 00:46:11 »
Quote from: Microfunguy on 10 / May / 2012, 19:25:57
Do I have a 'MINGW  installation' ?
Not really. You have some mingw based tools that someone put together in some poorly specified way. If you want a fully functional mingw environment for doing pc development, I'd suggest you go to http://www.mingw.org/
and install the full msys using the installer. That's what I use for chdkptp.

In effect, am I in a Unix environment?
Quote
When studying gcc compiling, it states the default locations for headers amd libraries is usr\local\include, usr\local\lib,usr\include and usr\lib.

How does that relate to my file structure on Windows ?

It makes the gcc discussions of relative paths difficult to understand.
They should be relative to the compiler location.
gcc -v --version
will give you some information. But in any case, when compiling/linking with additional 3rd party libraries, you should probably just use -I and -L
Quote
I have also found that gcc examples that place -I and -L folders before the .C files do not work, the compiler complains there are no 'c files.
Then you've messed something up, or the pre-configured toolchain you are using is messed up in some way.

Any directories with spaces must be quoted (or better, renamed). You should also always use / rather than \  in the command line and source files.

Note that the position of some options relative the file names does matter, particularly -l (lowercase L).
Logged
Don't forget what the H stands for.
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: Compiling problem when linking to external libraries.
« Reply #2 on: 11 / May / 2012, 08:43:14 »
Thanks reyalp, I will of course take your advice.
Let us proceed step-by-step, there will be issues.

First, if I run the MINGW installer will it affect my current ability to compile SDM\CHDK using gmake ?

Secondly, do I need MSYS initially ?

Certainly, if the prebuilt environment is 'suspect' it makes learning gcc by following code examples frustrating.
Logged
*

Offline reyalp

  • ******
  • 14128
Re: Compiling problem when linking to external libraries.
« Reply #3 on: 11 / May / 2012, 23:29:10 »
Quote from: Microfunguy on 11 / May / 2012, 08:43:14
First, if I run the MINGW installer will it affect my current ability to compile SDM\CHDK using gmake ?
Not unless you put the mingw stuff on your path. It doesn't add itself to the system path.

I actually use the msys bash shell, make and x86 compiler for chdk development.
Quote
Secondly, do I need MSYS initially ?
Probably not, but it if disk space isn't a worry, it might be simpler just to install everything. msys basically gives you a bash shell and a set of unix-like tools. Without it, you just get the compilers etc (I think, I've never installed it without msys)
Quote
Certainly, if the prebuilt environment is 'suspect' it makes learning gcc by following code examples frustrating.
It's not clear to me if the issue you are having is really a problem with the tool chain, but it was put together to be just enough to build chdk rather than being a full development environment. The old pre-built gcc 3.x toolchain only runs under XP, so I can't easily reproduce what you were trying to do.
Logged
Don't forget what the H stands for.
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: Compiling problem when linking to external libraries.
« Reply #4 on: 18 / May / 2012, 19:07:05 »
Quote from: reyalp on 11 / May / 2012, 00:46:11
They should be relative to the compiler location.
gcc -v --version
will give you some information.

For the record, this is what it displays :-

Code: [Select]
Reading specs from H:/chdk/gcc/bin/../lib/gcc-lib/mingw32/3.2.3/specs

Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32
--prefix=/mingw --enable-threads --disable-nls --enable-languages=c++,f77,objc --disable-win32-registry
--disable-shared --enable-sjlj-exceptions

Thread model: win32

gcc version 3.2.3 (mingw special 20030504-1)

Guess I will have to research those options.

Then I will install MINGW.

« Last Edit: 18 / May / 2012, 19:08:39 by Microfunguy »
Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: Compiling problem when linking to external libraries.
« Reply #5 on: 18 / May / 2012, 19:43:02 »
OK, MINGW and MSYS installed and SDM still compiles (not sure if it is still using sh/zsh.exe or the shell provided with MINGW).

4.6.3 manual downloaded  ..... 730 pages !
« Last Edit: 19 / May / 2012, 09:46:31 by Microfunguy »
Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: Compiling problem when linking to external libraries.
« Reply #6 on: 22 / May / 2012, 15:00:09 »
Well, almost there but not quite.

I have a static library at "./gd/libgd.a" and its header file at "./gd/gd.h"

In the header file, we have this macro :-

#ifdef NONDLL
#define BGD_DECLARE(rt) extern rt
#else

I have #define NONDLL 1
The macro simply makes all the function declarations external (rather than for a linked library).

The makefile is :-

Code: [Select]
CC=gcc
CFLAGS=-W -Wall -O3 -s -D_FILE_OFFSET_BITS=64 -mms-bitfields -mtune=i686 -march=i386
IFLAGS= -I"./gd"
LDFLAGS= "./gd/libbgd.a" -L/MinGW/lib/libavc  -lavcodec -lavformat -lavcodec -lswscale -lavutil -lz


all: mtn

mtn:  mytest.c 
$(CC) -o mythumb mythumb.c  $(CFLAGS) $(IFLAGS) $(LDFLAGS)

mtns: mytest.c 
$(CC) -o mtns mytest.c -static $(CFLAGS)$(IFLAGS) $(LDFLAGS)

test: test.c 
$(CC) -o test test.c $(CFLAGS) $(IFLAGS) $(LDFLAGS)

clean:
rm -f mytest.exe mtns.exe test.exe


Needless to say, the compiler gives "undefined reference to" for any function in libgd.a after typing 'make mtns'.


What is the problem ?

« Last Edit: 22 / May / 2012, 15:02:09 by Microfunguy »
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Compiling problem when linking to external libraries.
« Reply #7 on: 22 / May / 2012, 15:59:57 »
Quote from: Microfunguy on 22 / May / 2012, 15:00:09

I have a static library at "./gd/libgd.a" and its header file at "./gd/gd.h"

The makefile is :-

Code: [Select]
LDFLAGS= "./gd/libbgd.a" -L/MinGW/lib/libavc  -lavcodec -lavformat -lavcodec -lswscale -lavutil -lz




Two possible problems:
- missing '-l' on ./gd/libgd.a in LDFLAGS
- spelling of libbgd in LDFLAGS

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: Compiling problem when linking to external libraries.
« Reply #8 on: 22 / May / 2012, 18:09:27 »
Quote from: philmoz on 22 / May / 2012, 15:59:57
Two possible problems:
- missing '-l' on ./gd/libgd.a in LDFLAGS

No, that just produces "cannot find -l./gd/libbgd.a"

Quote
- spelling of libbgd in LDFLAGS

No, that was a mistake in my post.
It really is libbgd.a.

If I execute ar t libbgd.a I get a list :-


dt.o
dh.o
ds00137.o
ds00136.0

etc

Looking at the file with a hex editor, at the start I see the function names.
A typical pair for each function is :-

_gdImageCopy@32
__imp__gdImageCopy@32

despite the naming convention used, the documentation describes libbgd.a as an import library.
« Last Edit: 22 / May / 2012, 22:00:40 by Microfunguy »
Logged
*

Offline reyalp

  • ******
  • 14128
Re: Compiling problem when linking to external libraries.
« Reply #9 on: 23 / May / 2012, 00:24:44 »
Quote from: Microfunguy on 22 / May / 2012, 18:09:27
Quote from: philmoz on 22 / May / 2012, 15:59:57
Two possible problems:
- missing '-l' on ./gd/libgd.a in LDFLAGS

No, that just produces "cannot find -l./gd/libbgd.a"
-l generally does not take a complete path or filename. Normally, you would do something like
-Lpath/to/gd -lbgd

Note that position of -l relative to object files and other libraries matters. See http://gcc.gnu.org/onlinedocs/gcc-4.6.3/gcc/Link-Options.html#Link-Options

Logged
Don't forget what the H stands for.
Pages: [1] 2   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal