Only static linking (Linux)?
joost
Could be a newbie question, but I seem to be the first one in the list
to wonder about it.
Why only --static linking for Linux? Building the hello thingy results
in a code size of 450K(!).
Simply removing the --static produces a linker error, so apparently
this is a must-be-as-it-is?
Thanx,
joost.
Tarun Tuli
Im not sure why removing the --static produces a linker error. You
may not be including the appropriate libraries in the linker command
line. What is the specific error you get and can you post your
Makefile?
Anyways, static libraries are not a necessity. Shared libraries can
be used by placing them in your /usr/lib directory on the VCMX212.
The only downside is a slight reduction in performance and less easy
portability between different boards with different builds.
-Tarun
Joost 't Hart
At 15:56 25-05-2008, you wrote:
>Hi Joost.
>
>Im not sure why removing the --static produces a linker error. You
>may not be including the appropriate libraries in the linker command
>line. What is the specific error you get and can you post your
>Makefile?
I just used the info and file from the Wiki (so no makefile):
The following command line is the one that does (not, note that I
deliberately removed the --static from the end) do the job.
$ arm-linux-gcc -o hello hello.c
/opt/crosstool/gcc-4.0.2-glibc-2.3.2/arm-linux/lib/gcc/arm-linux/4.0.2/../../../../arm-linux/bin/ld:
cannot find -lgcc_s
collect2: ld returned 1 exit status
>Anyways, static libraries are not a necessity. Shared libraries can
>be used by placing them in your /usr/lib directory on the VCMX212.
Right. Can you suggest a link to some info suggesting what libraries
to copy (from where)?
>The only downside is a slight reduction in performance
Understood.
>and less easy portability between different boards with different builds.
This one I do not fully grasp. I can even imagine that the opposite
could be the case, with potential non-portable elements outside the
application binary.
By the way, we should not forget about the download time. The 450K
takes several minutes to transfer using the Xmodem, which for serious
applications is a bit harsh during development and debugging stages.
Regards,
joost
Tarun Tuli
> The following command line is the one that does (not, note that I
> deliberately removed the --static from the end) do the job.
>
> $ arm-linux-gcc -o hello hello.c
> /opt/crosstool/gcc-4.0.2-glibc-2.3.2/arm-linux/lib/gcc/arm-linux/4.0.2/../../../../arm-linux/bin/ld:
> cannot find -lgcc_s
> collect2: ld returned 1 exit status
>
Try throwing a -lgcc argument on the command line.
>
>>Anyways, static libraries are not a necessity. Shared libraries can
>>be used by placing them in your /usr/lib directory on the VCMX212.
>
> Right. Can you suggest a link to some info suggesting what libraries
> to copy (from where)?
The libraries should all be in your toolchains lib directory. What
libraries you need depend on what your binary requires. Usually you
need libc, liba and libgcc.
>
>>The only downside is a slight reduction in performance
>
> Understood.
>
>>and less easy portability between different boards with different builds.
>
> This one I do not fully grasp. I can even imagine that the opposite
> could be the case, with potential non-portable elements outside the
> application binary.
If you are distributing the binary between boards with shared
libraries, you need to ensure that the libraries on all the boards is
(a) present (b) compatible with your binary.
>
> By the way, we should not forget about the download time. The 450K
> takes several minutes to transfer using the Xmodem, which for serious
> applications is a bit harsh during development and debugging stages.
>
We often use NFS coupled with the Ethernet COG to transfer files quickly.
-Tarun
Joost 't Hart
Some extra info, and I mention this without intention to frustrate anyone.
I decided to download and build the 0.43 Linux cross toolchain
myself, and see what would happen to the problem described before:
Surprise, surprise, it builds without problems, both static and
shared. With shared libs, the binary size has gone down to 6937 bytes. Lovely.
To be fair, I did not have a chance yet to test it on the target.
First thing in the morning, when I also may need to play a bit with
those shared libraries sitting on the target...
I will keep you posted, if you do not mind.
Anyway, does this mean that something has gone astray with the
pre-compiled distribution?
Regards,
joost
Joost 't Hart
>Hi,
>
>Some extra info, and I mention this without intention to frustrate anyone.
>
>I decided to download and build the 0.43 Linux cross toolchain
>myself, and see what would happen to the problem described before:
>Surprise, surprise, it builds without problems, both static and
>shared. With shared libs, the binary size has gone down to 6937 bytes. Lovely.
>
>To be fair, I did not have a chance yet to test it on the target.
>First thing in the morning, when I also may need to play a bit with
>those shared libraries sitting on the target...
>
>I will keep you posted, if you do not mind.
Running and working!
Additional steps to be taken were nicely described by Magnus in this
forum
(http://groups.google.com/group/virtualcogs/browse_thread/thread/a0413bdfbcdfa9c4?hl=en#).
Thanks!.
Maybe one additional explicitness:
/lib and /lib/* need +x attributes.
>Anyway, does this mean that something has gone astray with the
>pre-compiled distribution?
>
>Regards,
>joost
<zip>
Joost 't Hart
>Hi Joost
>
> > The following command line is the one that does (not, note that I
> > deliberately removed the --static from the end) do the job.
> >
> > $ arm-linux-gcc -o hello hello.c
> >
> /opt/crosstool/gcc-4.0.2-glibc-2.3.2/arm-linux/lib/gcc/arm-linux/4.0.2/../../../../arm-linux/bin/ld:
> > cannot find -lgcc_s
> > collect2: ld returned 1 exit status
> >
>
>Try throwing a -lgcc argument on the command line.
No mercy.
For some reason it takes quite some time for my postings to go
through, but I managed to solve things (see other follow-up).
> >
> >>Anyways, static libraries are not a necessity. Shared libraries can
> >>be used by placing them in your /usr/lib directory on the VCMX212.
> >
> > Right. Can you suggest a link to some info suggesting what libraries
> > to copy (from where)?
>
>The libraries should all be in your toolchains lib directory. What
>libraries you need depend on what your binary requires. Usually you
>need libc, liba and libgcc.
>
> >
> >>The only downside is a slight reduction in performance
> >
> > Understood.
> >
> >>and less easy portability between different boards with different builds.
> >
> > This one I do not fully grasp. I can even imagine that the opposite
> > could be the case, with potential non-portable elements outside the
> > application binary.
>
>If you are distributing the binary between boards with shared
>libraries, you need to ensure that the libraries on all the boards is
>(a) present (b) compatible with your binary.
Sure, but, hm, maybe we should not dwell into fundamentalism here,
but this seems to be more a deployment (distribution, indeed) than a
portability issue.