undefined reference to symbol 'pow@@GLIBC_2.0'
Guy Roussin
I get this error when i try to compile harbour on debian sid (i386)
$ svn update
À la révision 16340.
$ make clean
...
$ dpkg-buildpackage -rfakeroot -uc -b
...
make[2]: entrant dans le répertoire « /usr/local/src/harbour/utils »
make[3]: entrant dans le répertoire « /usr/local/src/harbour/utils/hbmk2 »
make[4]: entrant dans le répertoire « /usr/local/src/harbour/utils/hbmk2/obj/linux/gcc »
../../../../../bin/linux/gcc/harbour ../../../hbmk2.prg -i../../../../../include -n1 -q0
-w3 -es2 -kmo -i- -l -DHB_HAS_GPM
gcc -I. -I../../../../../include -W -Wall -O3 -DHB_LEGACY_TYPES_OFF -ohbmk2.o -c hbmk2.c
gcc -L../../../../../lib/linux/gcc -o../../../../../bin/linux/gcc/hbmk2 hbmk2.o
-lhbcplr -lhbpp -lhbcommon -lhbcplr -lhbdebug -lharbour-2.1.0
/usr/bin/ld: ../../../../../lib/linux/gcc/libhbcommon.a(expropt2.o): undefined reference
to symbol 'pow@@GLIBC_2.0'
/usr/bin/ld: note: 'pow@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try adding it to
the linker command line
/lib/libm.so.6: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[4]: *** [hbmk2] Erreur 1
make[4]: quittant le répertoire « /usr/local/src/harbour/utils/hbmk2/obj/linux/gcc »
make[3]: *** [descend] Erreur 2
make[3]: quittant le répertoire « /usr/local/src/harbour/utils/hbmk2 »
make[2]: *** [hbmk2] Erreur 2
make[2]: quittant le répertoire « /usr/local/src/harbour/utils »
make[1]: *** [utils] Erreur 2
make[1]: quittant le répertoire « /usr/local/src/harbour »
make: *** [build-stamp] Erreur 2
dpkg-buildpackage: erreur: debian/rules build a produit une erreur de sortie de type 2
--
Guy
Guy Roussin
I can fix this error if i add -lm at the end of the line :
gcc -L../../../../../lib/linux/gcc -o../../../../../bin/linux/gcc/hbmk2 hbmk2.o -lhbcplr
-lhbpp -lhbcommon -lhbcplr -lhbdebug -lharbour-2.1.0
like this :
gcc -L../../../../../lib/linux/gcc -o../../../../../bin/linux/gcc/hbmk2 hbmk2.o -lhbcplr
-lhbpp -lhbcommon -lhbcplr -lhbdebug -lharbour-2.1.0 -lm
Where can i add '-lm' in the Makefile stuff ?
Thank you
Guy
Viktor Szakáts
<guy.r...@teledetection.fr> wrote:
> Hi,
>
> I can fix this error if i add -lm at the end of the line :
> gcc -L../../../../../lib/linux/gcc -o../../../../../bin/linux/gcc/hbmk2
> hbmk2.o -lhbcplr -lhbpp -lhbcommon -lhbcplr -lhbdebug -lharbour-2.1.0
> like this :
> gcc -L../../../../../lib/linux/gcc -o../../../../../bin/linux/gcc/hbmk2
> hbmk2.o -lhbcplr -lhbpp -lhbcommon -lhbcplr -lhbdebug -lharbour-2.1.0 -lm
>
> Where can i add '-lm' in the Makefile stuff ?
It's easy to add it, and in fact it's currently explicitly disabled for
shared builds. Until someone explains why this is suddenly required
in this specific Linux version (which seems to be an unstable
build AFAICS) I don't plan to touch it.
Viktor
Tamas TEVESZ
> > I can fix this error if i add -lm at the end of the line :
> > gcc -L../../../../../lib/linux/gcc -o../../../../../bin/linux/gcc/hbmk2
> > hbmk2.o -lhbcplr -lhbpp -lhbcommon -lhbcplr -lhbdebug -lharbour-2.1.0
> > like this :
> > gcc -L../../../../../lib/linux/gcc -o../../../../../bin/linux/gcc/hbmk2
> > hbmk2.o -lhbcplr -lhbpp -lhbcommon -lhbcplr -lhbdebug -lharbour-2.1.0 -lm
> >
> > Where can i add '-lm' in the Makefile stuff ?
>
> It's easy to add it, and in fact it's currently explicitly disabled for
> shared builds. Until someone explains why this is suddenly required
> in this specific Linux version (which seems to be an unstable
> build AFAICS) I don't plan to touch it.
coincidentally, i have just bumped into this on solaris (not on linux,
though).
i vaugely remember having already been there, and i am four-nines per
cent sure that explicitly adding -lm is not the solution.
i'll try to dig it up.
--
[-]
mkdir /nonexistent
Tamas TEVESZ
this seems to be what i was referring to:
http://www.mail-archive.com/har...@harbour-project.org/msg18490.html
http://www.mail-archive.com/har...@harbour-project.org/msg18498.html
but this isn't it.
guy, run `readelf -d' on *all* libharbour.sos you find lying around
(including but possibly not limited to your currently installed
/usr/lib/{harbour/,}/libharbour.so* as well as the one just being
built in the debian/ area, but obviously skip the symlinks), and post
the results, complete with the location of said libharbours, your
environment, and the top of the build log (the piece that shows the
build settings as seen by the build system), and post that (targz'd if
too big or a link or something).
--
[-]
mkdir /nonexistent
Przemysław Czerpak
Hi,
If harbour shared library is linked with math library (-lm) then
it should be available also for other code linked with harbour shared
library.
So I'd suggest to check if harbour*.so* is really linked with -lm
(i.e. using: ldd harbour*.so*). If it isn't then we should check
why and fix our build process. If it is and GCC still fails to link
final application then it's probably a problem with local configuration,
i.e. someone added some security "fixes" and disabled automatic library
inheritance. If this is the reason and author does not plan to fix such
"fix" then we will have to suggest other Linux distribution or add/document
some workarounds for it (i.e.: export HB_USER_LDFLAGS=-lm)
Anyhow before we change anything I would like that someone verify what
is the exact reason of problem and if it still exists in clean SVN builds).
best regards,
Przemek
Tamas TEVESZ
hi,
> If harbour shared library is linked with math library (-lm) then
> it should be available also for other code linked with harbour shared
> library.
> So I'd suggest to check if harbour*.so* is really linked with -lm
> (i.e. using: ldd harbour*.so*). If it isn't then we should check
> why and fix our build process. If it is and GCC still fails to link
> final application then it's probably a problem with local configuration,
> i.e. someone added some security "fixes" and disabled automatic library
> inheritance. If this is the reason and author does not plan to fix such
> "fix" then we will have to suggest other Linux distribution or add/document
> some workarounds for it (i.e.: export HB_USER_LDFLAGS=-lm)
> Anyhow before we change anything I would like that someone verify what
> is the exact reason of problem and if it still exists in clean SVN builds).
ok, i think i got it. it's actually more mundane :)
the original failing linker line guy reported reads as:
gcc -L../../../../../lib/linux/gcc
-o../../../../../bin/linux/gcc/hbmk2 hbmk2.o
-lhbcplr -lhbpp -lhbcommon -lhbcplr
-lhbdebug -lharbour-2.1.0
whereas my also failing sunos linker line reads as:
gcc -L../../../../../lib/sunos/gcc -L/opt/csw/lib
-o../../../../../bin/sunos/gcc/hbmk2 hbmk2.o
-lhbcplr -lhbpp -lhbcommon -lhbcplr
-lhbdebug -lharbour
they are for all intents and purposes identical. while i can't speak
for guy's case, in my case libharbour.so* is linked against libmath
$ ldd ../../../../../lib/sunos/gcc/libharbour.so | fgrep libm.
libm.so.2 => /lib/libm.so.2
i suppose his looks like this, too.
but, the missing symbol is reported to be in expropt2.o
(libhbcommon.a) in both guys and my cases, which is listed way before
libharbour, which would then pull in libm. so let's shuffle things
around a bit:
$ gcc -L../../../../../lib/sunos/gcc -L/opt/csw/lib
-o../../../../../bin/sunos/gcc/hbmk2 hbmk2.o
-lharbour -lhbcplr -lhbpp -lhbcommon
-lhbcplr -lhbdebug
et voila
$ LD_LIBRARY_PATH=`pwd`/../../../../../lib/sunos/gcc ../../../../../bin/sunos/gcc/hbmk2
Harbour Make (hbmk2) 2.1.0rc2 (Rev. 16370)
so from what i can tell, the problem does exist, and the real solution
is to feed the libraries in the correct order to the linker.
why does it not surface in (apparently) most of the cases, my guess is
as good as anyone's.
--
[-]
mkdir /nonexistent
Viktor Szakáts
> On Wed, 23 Feb 2011, Przemysław Czerpak wrote:
>
> hi,
>
>> If harbour shared library is linked with math library (-lm) then
>> it should be available also for other code linked with harbour shared
>> library.
>> So I'd suggest to check if harbour*.so* is really linked with -lm
>> (i.e. using: ldd harbour*.so*). If it isn't then we should check
>> why and fix our build process. If it is and GCC still fails to link
>> final application then it's probably a problem with local configuration,
>> i.e. someone added some security "fixes" and disabled automatic library
>> inheritance. If this is the reason and author does not plan to fix such
>> "fix" then we will have to suggest other Linux distribution or add/document
>> some workarounds for it (i.e.: export HB_USER_LDFLAGS=-lm)
>> Anyhow before we change anything I would like that someone verify what
>> is the exact reason of problem and if it still exists in clean SVN builds).
>
> ok, i think i got it. it's actually more mundane :)
>
> the original failing linker line guy reported reads as:
>
> gcc -L../../../../../lib/linux/gcc
> -o../../../../../bin/linux/gcc/hbmk2 hbmk2.o
> -lhbcplr -lhbpp -lhbcommon -lhbcplr
> -lhbdebug -lharbour-2.1.0
Hm, this looks wrong as the dynlib should not have the version included,
it seems temp problem fixed since then. Maybe worth a new try
with current svn. I hope Guy can do it.
if problem persist in current svn, we may try to tweak it,
here another solution - with less impact - is to enable lib
grouping. Finding "correct order" for all targets seems
to be difficult.
Viktor
Guy Roussin
Thank you Viktor, Tamas and Przemek
>> they are for all intents and purposes identical. while i can't speak
>> for guy's case, in my case libharbour.so* is linked against libmath
>>
>> $ ldd ../../../../../lib/sunos/gcc/libharbour.so | fgrep libm.
>> libm.so.2 => /lib/libm.so.2
Same here
>> but, the missing symbol is reported to be in expropt2.o
>> (libhbcommon.a) in both guys and my cases, which is listed way before
>> libharbour, which would then pull in libm. so let's shuffle things
>> around a bit:
>>
>> $ gcc -L../../../../../lib/sunos/gcc -L/opt/csw/lib
>> -o../../../../../bin/sunos/gcc/hbmk2 hbmk2.o
>> -lharbour -lhbcplr -lhbpp -lhbcommon
>> -lhbcplr -lhbdebug
>>
>> et voila
Same here. If i put lharbour first it fixes the error.
> if problem persist in current svn, we may try to tweak it,
> here another solution - with less impact - is to enable lib
> grouping. Finding "correct order" for all targets seems
> to be difficult.
Yes, the problem persist in current svn
Guy
Viktor Szakáts
Thanks.
My problem is that if I move it in front I break a lot of
other targets (f.e. the first I happened to try: win/mingw).
[ it could be fixed by moving hbmainstd before harbour dll)
I'm also not sure it's a good idea to use different order
depending on platform, it'd be good to find one which
universally looks good (like current one, which so far
worked everywhere). All in all I still don't feel having enough
information to dare stirring this matter, and I certainly
wouldn't like to break any random platform to fix a case
where we don't know the exact reasons/scope. Looks
like an avalanche of changes and retesting all combinations
on all targets.
Plus, also hbmk2 puts harbour dynlib at the end of lib list.
So I'm waiting for more tips and suggestions how to
fix this universally or how to fix this specific case without
reinventing everything. We can also reinvent everything,
but this should be done after release and with proper
planning of lib order; there are about 7-8 lib categories
to put in proper order.
Viktor
Tamas TEVESZ
> So I'm waiting for more tips and suggestions how to
> fix this universally or how to fix this specific case without
> reinventing everything. We can also reinvent everything,
> but this should be done after release and with proper
> planning of lib order; there are about 7-8 lib categories
> to put in proper order.
that's what lib grouping is supposed to be good for, no?
i've been fighting with it for a bit now, but it does not seem to bend
yet...
--
[-]
mkdir /nonexistent
Viktor Szakáts
> > fix this universally or how to fix this specific case without
> > reinventing everything. We can also reinvent everything,
> > but this should be done after release and with proper
> > planning of lib order; there are about 7-8 lib categories
> > to put in proper order.
>
> that's what lib grouping is supposed to be good for, no?
>
> i've been fighting with it for a bit now, but it does not seem to bend
> yet...
I'm not much fan of lib grouping. It hits linker performance badly,
so f.e. in core build it's not used at all now.
In hbmk2 it still is enabled (on gcc platforms), can't remember
why I had to add it, but the direction is to avoid it there also. Pbly
this would be a good time to give it a thought. Now it can be
disabled with -nolibgrouping option, which is planned to be
made default, once it has been fully sorted.
[ for one thing, our own core libs make various cross references,
which is not good, but these can be fixed by cleverly adding some
of them multiple time to the lib list. Cleaning this situation would
be better, but it's quite huge job touching stuff laid ages ago. ]
Viktor
Viktor Szakáts
Tamas TEVESZ
> > > So I'm waiting for more tips and suggestions how to
> > > fix this universally or how to fix this specific case without
> > > reinventing everything. We can also reinvent everything,
> > > but this should be done after release and with proper
> > > planning of lib order; there are about 7-8 lib categories
> > > to put in proper order.
> >
> > that's what lib grouping is supposed to be good for, no?
> >
> > i've been fighting with it for a bit now, but it does not seem to bend
> > yet...
>
> I'm not much fan of lib grouping. It hits linker performance badly,
> so f.e. in core build it's not used at all now.
ok, i thought i understood how it works, but no joy.
sparky:~/w/xhb/hbci/harbour-build/utils/hbmk2/obj/sunos/gcc$ gcc -L../../../../../lib/sunos/gcc -L/opt/csw/lib
-o../../../../../bin/sunos/gcc/hbmk2
-Wl,--start-group hbmk2.o -lhbcplr -lhbpp -lhbcommon -lhbcplr -lhbdebug -lharbour -Wl,--end-group
Undefined first referenced
symbol in file
pow ../../../../../lib/sunos/gcc/libhbcommon.a(expropt2.o) (symbol belongs to implicit dependency /usr/lib/libm.so.2)
fmod ../../../../../lib/sunos/gcc/libhbcommon.a(expropt2.o) (symbol belongs to implicit dependency /usr/lib/libm.so.2)
modfl ../../../../../lib/sunos/gcc/libhbcommon.a(hbprintf.o) (symbol belongs to implicit dependency /usr/lib/libm.so.2)
ld: fatal: symbol referencing errors. No output written to ../../../../../bin/sunos/gcc/hbmk2
what's wrong with this?
--
[-]
mkdir /nonexistent
Viktor Szakáts
Dunno... does sunos support lib grouping at all?
and... is this a new problem, or was this one there all along?
Viktor
Tamas TEVESZ
> > ok, i thought i understood how it works, but no joy.
> >
> > sparky:~/w/xhb/hbci/harbour-build/utils/hbmk2/obj/sunos/gcc$ gcc -L../../../../../lib/sunos/gcc -L/opt/csw/lib
> > -o../../../../../bin/sunos/gcc/hbmk2
> > -Wl,--start-group hbmk2.o -lhbcplr -lhbpp -lhbcommon -lhbcplr -lhbdebug -lharbour -Wl,--end-group
> > Undefined first referenced
> > symbol in file
> > pow ../../../../../lib/sunos/gcc/libhbcommon.a(expropt2.o) (symbol belongs to implicit dependency /usr/lib/libm.so.2)
> > fmod ../../../../../lib/sunos/gcc/libhbcommon.a(expropt2.o) (symbol belongs to implicit dependency /usr/lib/libm.so.2)
> > modfl ../../../../../lib/sunos/gcc/libhbcommon.a(hbprintf.o) (symbol belongs to implicit dependency /usr/lib/libm.so.2)
> > ld: fatal: symbol referencing errors. No output written to ../../../../../bin/sunos/gcc/hbmk2
> >
> > what's wrong with this?
>
> Dunno... does sunos support lib grouping at all?
well, according to the ld manual, it does:
-z rescan-start ... -z rescan-end
--start-group ... --end-group
-( ... -)
Defines an archive rescan group. This is a positional
construct, and is processed by the link-editor immedi-
ately upon encountering the closing delimiter option.
Archives found within the group delimiter options are
reprocessed as a group in an attempt to locate addi-
tional archive members that resolve symbol references.
This archive rescanning is repeated until a pass over
the archives On the occurs in which no new members are
extracted. Archive rescan groups cannot be nested.
i guess what i should have asked is "is this how lib grouping supposed
to work", generally?
(this though is a new option that appeared in sol11 express, currently
production sol 10 does not have it. at this point i'm just trying to
do anything to make it work, and then possibly backtrack from there.)
> and... is this a new problem, or was this one there all along?
i don't know how new it is, i haven't built solaris in a while. i just
had a chance to do a bit of a hardware upgrade which cuts build times
in half, so i started doing doing it again. (also, experience shows
that after these sorts of operations that tend to affect toolchain
usage, best is to re-test everything ;)
--
[-]
mkdir /nonexistent
Tamas TEVESZ
> > Dunno... does sunos support lib grouping at all?
>
> well, according to the ld manual, it does:
i found one variation where it does work:
sparky:~/w/xhb/hbci/harbour-build/utils/hbmk2/obj/sunos/sunpro$ suncc
-L../../../../../lib/sunos/sunpro -o ../../../../../bin/sunos/sunpro/hbmk2
-Wl,--start-group
-lhbcplr -lhbpp -lhbcommon -lhbcplr -lhbdebug -lharbour
hbmk2.o
-Wl,--end-group
so move hbmk2.o to the end, _and_ put the whole shebang into a group.
it doesn't work otherwise (hbmk2.o outside the group or before the lib
list).
without resorting to grouping, the only way so far is to move
-lharbour to be the first in the lib list.
still can't reproduce this on linux, though.
--
[-]
mkdir /nonexistent
Tamas TEVESZ
> without resorting to grouping, the only way so far is to move
> -lharbour to be the first in the lib list.
i give up, how do i do that? i would have thought HB_DYNLIB_BASE to
have something to do with this, but config/ isn't exactly riddled with
this ;)
--
[-]
mkdir /nonexistent
Viktor Szakáts
> > -lharbour to be the first in the lib list.
>
> i give up, how do i do that? i would have thought HB_DYNLIB_BASE to
> have something to do with this, but config/ isn't exactly riddled with
> this ;)
Try with this change in bin.mk:
--- bin.mk Thu Feb 24 19:32:09 2011
+++ bin-mod.mk Thu Feb 24 01:28:52 2011
@@ -17,21 +17,20 @@
endif
ifeq ($(BUILD_SHARED),yes)
- HB_LIBS_TPL := \
- hbcplr \
- hbdebug \
+
+ HB_LIBS_TPL_PRE :=
ifeq ($(HB_PLATFORM),cygwin)
- HB_LIBS_TPL += hbmainstd
+ HB_LIBS_TPL_PRE += hbmainstd
else
ifneq ($(filter $(HB_PLATFORM),win wce),)
ifneq ($(filter $(HB_COMPILER),mingw mingw64 mingwarm),)
- HB_LIBS_TPL += hbmainstd
+ HB_LIBS_TPL_PRE += hbmainstd
else
ifeq ($(HB_COMPILER),watcom)
HB_LDFLAGS += FILE $(LIB_DIR)/hbmainstd.lib
else
- HB_LIBS_TPL += hbmainstd hbmainwin
+ HB_LIBS_TPL_PRE += hbmainstd hbmainwin
endif
endif
else
@@ -39,14 +38,18 @@
ifeq ($(HB_COMPILER),watcom)
HB_LDFLAGS += FILE $(LIB_DIR)/hbmainstd.lib
else
- HB_LIBS_TPL += hbmainstd
+ HB_LIBS_TPL_PRE += hbmainstd
endif
endif
endif
endif
- HB_LIBS_ST_RDD := $(HB_LIBS_TPL) $(HB_DYNLIB_BASE)
- HB_LIBS_MT_RDD := $(HB_LIBS_TPL) $(HB_DYNLIB_BASE)
+ HB_LIBS_TPL := \
+ hbcplr \
+ hbdebug \
+
+ HB_LIBS_ST_RDD := $(HB_LIBS_TPL_PRE) $(HB_DYNLIB_BASE) $(HB_LIBS_TPL)
+ HB_LIBS_MT_RDD := $(HB_LIBS_TPL_PRE) $(HB_DYNLIB_BASE) $(HB_LIBS_TPL)
HB_LIBS_ST_NORDD := $(HB_LIBS_ST_RDD)
HB_LIBS_MT_NORDD := $(HB_LIBS_ST_RDD)
---
Viktor
Tamas TEVESZ
hi,
> Try with this change in bin.mk:
thanks. i added a bit of a debug here, like so (diff is too cranky):
HB_LIBS_TPL := \
hbcplr \
hbdebug \
$(info *** HB_LIBS_TPL_PRE =[$(HB_LIBS_TPL_PRE)])
$(info *** HB_DYNLIB_BASE =[$(HB_DYNLIB_BASE)])
$(info *** HB_LIBS_TPL =[$(HB_LIBS_TPL)])
HB_LIBS_ST_RDD := $(HB_LIBS_TPL_PRE) $(HB_DYNLIB_BASE) $(HB_LIBS_TPL)
HB_LIBS_MT_RDD := $(HB_LIBS_TPL_PRE) $(HB_DYNLIB_BASE) $(HB_LIBS_TPL)
HB_LIBS_ST_NORDD := $(HB_LIBS_ST_RDD)
HB_LIBS_MT_NORDD := $(HB_LIBS_ST_RDD)
$(info *** HB_LIBS_ST_RDD =[$(HB_LIBS_ST_RDD)])
$(info *** HB_LIBS_MT_RDD =[$(HB_LIBS_MT_RDD)])
$(info *** HB_LIBS_ST_NORDD =[$(HB_LIBS_ST_NORDD)])
$(info *** HB_LIBS_MT_NORDD =[$(HB_LIBS_MT_NORDD)])
HB_LIBS_TPL :=
and it's almost as if something was happening:
gmake[3]: `../../../../../lib/sunos/sunpro/libharbour.so.2.1.0' is up to date.
*** HB_LIBS_TPL_PRE =[]
*** HB_DYNLIB_BASE =[harbour]
*** HB_LIBS_TPL =[hbcplr hbdebug ]
*** HB_LIBS_ST_RDD =[ harbour hbcplr hbdebug ]
*** HB_LIBS_MT_RDD =[ harbour hbcplr hbdebug ]
*** HB_LIBS_ST_NORDD =[ harbour hbcplr hbdebug ]
*** HB_LIBS_MT_NORDD =[ harbour hbcplr hbdebug ]
*** HB_LIBS_TPL_PRE =[]
*** HB_DYNLIB_BASE =[harbour]
*** HB_LIBS_TPL =[hbcplr hbdebug ]
*** HB_LIBS_ST_RDD =[ harbour hbcplr hbdebug ]
*** HB_LIBS_MT_RDD =[ harbour hbcplr hbdebug ]
*** HB_LIBS_ST_NORDD =[ harbour hbcplr hbdebug ]
*** HB_LIBS_MT_NORDD =[ harbour hbcplr hbdebug ]
suncc -L../../../../../lib/sunos/sunpro -o
../../../../../bin/sunos/sunpro/hbmk2 hbmk2.o
-lhbcplr -lhbpp
-lhbcommon -lharbour
-lhbcplr -lhbdebug
but hbcplr and hbpp, together with hbcommon, sneak up to the front.
the fact that they are then added to the back would suggest that they
are not being prepended here.
oh fsck.
it's right there in utils/hbmk2/Makefile, LIBS = hbcplr hbpp hbcommon
$(HB_LIBS_MT_NORDD).
fixing that up (for now as LIBS = $(HB_LIBS_MT_NORDD) as this new
bin.mk takes care of adding the needed rest), and holy smokes, hbmk2!
where to go from here? it would seem that this patch of yours makes
the LIBS = hbcplr hbpp hbcommon $(HB_LIBS_MT_NORDD) stanza in hbmk2's
makefile superfluous, and LIBS = $(HB_LIBS_MT_NORDD) is just enough,
because bin.mk will supply the needed lib list, and in the correct
order, too. i don't think (know if) it's needed by any other
executable, though.
--
[-]
mkdir /nonexistent
Viktor Szakáts
if you're testing with building hbmk2, it's normal and intentional,
as they are explicitly listed in local Makefile. hbcplr is not part of
harbour lib and the other too is needed to avoid link error.
> the fact that they are then added to the back would suggest that they
> are not being prepended here.
>
> oh fsck.
>
> it's right there in utils/hbmk2/Makefile, LIBS = hbcplr hbpp hbcommon
> $(HB_LIBS_MT_NORDD).
Yes.
> fixing that up (for now as LIBS = $(HB_LIBS_MT_NORDD) as this new
> bin.mk takes care of adding the needed rest), and holy smokes, hbmk2!
That's why I was saying "avalanche" effect. Removing these
libs just broke some other targets (f.e. bcc).
> where to go from here? it would seem that this patch of yours makes
> the LIBS = hbcplr hbpp hbcommon $(HB_LIBS_MT_NORDD) stanza in hbmk2's
> makefile superfluous, and LIBS = $(HB_LIBS_MT_NORDD) is just enough,
> because bin.mk will supply the needed lib list, and in the correct
> order, too. i don't think (know if) it's needed by any other
> executable, though.
Unfortunately, it's needed. And here comes the fun part, finding
a least redundant, lib-grouping free, working in all build scenarios
lib order, which works with all supported targets.
Viktor