View Issue Details

IDProjectCategoryView StatusLast Update
0002075SOGoSOPEpublic2012-11-18 13:06
Reporterbuzzdee Assigned Towsourdeau 
Status closedResolutionfixed 
Product Version2.0.2 
Target Version2.0.3Fixed in Version2.0.3 
Summary0002075: fix for bug reports 0001615 and 0001616 break building on OpenBSD


the fixes to the bugs mentioned above contradict somehow my work ;)
the patch to SoObjects/SOGo/GNUmakefile.preamble from patch to bug 0001616
adds -ldl unconditionally. This one doesn't exist on OpenBSD.
In the same GNUmakefile.preamble, there is an

ifeq ($(findstring openbsd, $(GNUSTEP_HOST_OS)), openbsd)

so the -ldl could be added to the line in the else part, not disturbing OpenBSD.

further all patches add unconditional linking against -lobjc. In bug 2030
Wolfgang took my patch to remove such an unconditional linking.

On OpenBSD, the is installed as
Therefore is unconditional linking against -lobjc is bad bad bad, since
gnustep-make will also add -lobjc2 automatically too.

I don't know how to go on with that. Either remove this -lobjc again, what I would prefer, or have using a variable i.e. OBJCLIB=-lobjc which goes into the
main config.make. And then use $OBJCLIB everywhere where the -lobjc is used

then its easy for me, and maybe others to override for me on the command line:

make OBCLIB=-lobjc2 and I should get it right for me

Let me know how to proceed here.

TagsNo tags attached.




2012-10-26 17:29

viewer   ~0004717

Well, the act of linking against libobj should definitely be performed by gcc and from gnustep-make (at worse). And you are right: they have been put back.

Let me get back to you.



2012-10-26 17:56

reporter   ~0004718

Even when I don't have the -lobjc in the GNUmakefiles, I see when it comes to the linking stage the -lobjc2 automatically added. The same should be true for others having the -lobjc as default. gnustep-make should take care of that automagically.

Also, running ldd on the libraries, I see them being linked against libobjc2 in my case.




2012-10-26 18:06

reporter   ~0004720

I don't really understand why libobjc is installed as libobjc2, because the whole point of the version number at the end of the filename of libraries is that you can install for example and at the same time...

With regards to whether or not to link with libobjc: if I run objdump on I see that it uses at least three methods from libobjc directly (objc_get_class, objc_msg_lookup, objc_msg_lookup_super), so it should link with libobjc. Whether this linking is specified by gcc, gnustep or directly in the makefile doesn't really matter much, but if a library uses symbols from a different library it needs to link against it.

With regards to -ldl we should only link to that for the platforms that need it, that should be an easy fix.



2012-10-26 18:08

viewer   ~0004721

Dekkers: (as mentionned on irc)

It should not beneeded to specify it from the makefiles, because gcc "knows" which runtime library it uses. A makefile should not bother with this. the same way that issuing "gcc test.c -o test" will automatically link your program with the right libc.



2012-10-26 18:09

viewer   ~0004722


which version of gnustep-make are you using?



2012-10-26 22:09

reporter   ~0004724

Latest release: 2.6.2

@Dekkers: why its installed as libobjc? reason is just that it was decided that way when the libobjc2 port was introduced, to for example not clash at some point in time with system libobjc (in /usr/lib), or libobjc from a gcc port in /usr/local/lib.

gnustep-make is configured with parameter:


So whenever it links something, it automatically adds -lobjc2 instead of adding -lobjc, which is the default.

I think with the current GMakefiles, you see the -lobjc two times in the gcc parameters?

Since GNUstep Make takes care to link against the right runtime, there should be no need to tinker in GNUmakefiles with it.



2012-10-26 23:17

reporter   ~0004725

I just tested on Ubuntu 12.10 and I only see it once when linking, somehow gnustep-make doesn't care of it on Debian/Ubuntu...



2012-10-28 09:03

reporter   ~0004728

Then, maybe in configure stage, the libraries needed could be determined automatically and saved in a variable. I remembered, Richard did the something similar for gnustep-base. In gnustep-base there was also -lobjc hardcoded, he changed it to use gnustep-config --objc-libs.
Since we link against gnustep-base, we could use:
gnustep-config --base-libs

For me on OpenBSD this prints out:
-Wl,-E -L/usr/local/lib -pthread -shared-libgcc -fexceptions -fgnu-runtime -L/home/sebastia/GNUstep/Library/Libraries -L/usr/local/lib -L/usr/local/lib -lgnustep-base -lobjc2 -lm

or on an older system, linking against -lobjc from gcc, it prints:
-Wl,-E -pthread -fgnu-runtime -L/home/sebastia/GNUstep/Library/Libraries -L/usr/local/lib -L/usr/local/lib -lgnustep-base -pthread -lobjc -lm

This could be saved in a variable, and used all over the place, instead of the hardcoded information. This way SOPE/SOGo should get it always right.

So how about that one then?



2012-11-01 16:26

reporter   ~0004766

I don't have any problem with replacing the explicit linking with the output of gnustep-config --base-libs.



2012-11-07 15:14

viewer   ~0004788

This has now been done.



2012-11-10 15:10

reporter   ~0004821


I found a similar issue with gnustep's SQLClient library. They just fixed it after my report with exchanging:
-lgnustep-base -lobjc
The diff I'm talking about, you can find here:

Those two variables are defined in makefiles that get installed with gnustep-make and gnustep-base.

I wasn't aware of those variables before, but I think now this would be the cleanest way to link against gnustep base and libobjc, when desired.



2012-11-17 21:28

administrator   ~0004872

With the changes from comment 0004788, are we now all set with that bug and can close it?



2012-11-18 07:11

reporter   ~0004877

From my side, yes, even given I did not checked what you have done when you said its fixed. A link to the git was missing ;)
I only wanted to point out that there is a probably more clean way than the one I first proposed. So, if you think its fine with you, fine for me too.
When the time comes to upgrade to 2.0.3, and things are not as expected, I'll open another one.



2012-11-18 13:06

administrator   ~0004879

We now use "gnustep-config --base-libs" in both SOGo and SOPE's configure scripts.

Issue History

Date Modified Username Field Change
2012-10-26 10:32 buzzdee New Issue
2012-10-26 17:29 wsourdeau Note Added: 0004717
2012-10-26 17:29 wsourdeau Status new => confirmed
2012-10-26 17:29 wsourdeau Status confirmed => assigned
2012-10-26 17:29 wsourdeau Assigned To => wsourdeau
2012-10-26 17:56 buzzdee Note Added: 0004718
2012-10-26 18:06 dekkers Note Added: 0004720
2012-10-26 18:08 wsourdeau Note Added: 0004721
2012-10-26 18:09 wsourdeau Note Added: 0004722
2012-10-26 22:09 buzzdee Note Added: 0004724
2012-10-26 23:17 dekkers Note Added: 0004725
2012-10-28 09:03 buzzdee Note Added: 0004728
2012-10-29 15:47 wsourdeau Target Version => 2.0.3
2012-11-01 16:26 dekkers Note Added: 0004766
2012-11-07 15:14 wsourdeau Note Added: 0004788
2012-11-07 15:14 wsourdeau Status assigned => resolved
2012-11-07 15:14 wsourdeau Fixed in Version => 2.0.3
2012-11-07 15:14 wsourdeau Resolution open => fixed
2012-11-10 15:10 buzzdee Note Added: 0004821
2012-11-10 15:10 buzzdee Status resolved => feedback
2012-11-10 15:10 buzzdee Resolution fixed => reopened
2012-11-17 21:28 ludovic Note Added: 0004872
2012-11-18 07:11 buzzdee Note Added: 0004877
2012-11-18 13:06 ludovic Note Added: 0004879
2012-11-18 13:06 ludovic Status feedback => closed
2012-11-18 13:06 ludovic Resolution reopened => fixed